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BXECDTIVE  SDMMARY 

The  overall  objective  of  the  Department  of  Defense  Computer-aided 
Acquisition  &  Logistic  Support  (CALS)  Program  is  to  integrate  the 
design,  manufacturing,  and  logistic  functions  through  the 
efficient  application  of  computer  technology.  CALS  is  a  program 
to  apply  existing  and  emerging  communications  and  computer-aided 
technologies  in  DoD  and  industry  to: 

o  Integrate  and  improve  design,  manufacturing,  and 

logistic  fxinctions;  thereby  bridging  existing  "islands 
of  automation." 

o  Actively  influence  the  design  process  to  produce  weapon 
systems  that  are  more  reliable  and  easier  to  support 
and  maintain. 

o  Shift  from  current  paper- intensive  weapon  support 

processes  to  a  highly  automated  mode  of  operation, 
based  on  a  unified  DoO  interface  with  industry  for 

exchange  of  logistic  technical  information  in  digital 
form. 

The  CALS  program  was  established  by  the  Deputy  Secretary  of 

Defense  in  September  1985  to  implement  the  recommendations  of  a 
Joint  Industry/DoD  Task  Force.  Management  is  provided  by  a  DoD 
Steering  Group,  an  OSD  CALS  Policy  Office,  and  their  counterparts 
in  each  Military  Department  and  the  Defense  Logistics  Agency. 
The  CALS  Policy  Office  has  obtained  the  support  of  the  National 
Bureau  of  Standards  in  the  selection  and  implementation  of  CALS 
standards.  An  Industry  Steering  Group  has  also  been  established 
to  focus  the  work  of  key  industrial  associations  and  the  defense 
contractor  community  in  CALS  implementation. 

The  Bureau  has  been  funded  since  Spring  1986  to  recommend  a  suite 
of  industry  standards  for  system  integration  and  digital  data 
transfer,  and  to  accelerate  their  implementation.  NBS  activities 
during  1986  were  primarily  aimed  at: 

o  familiarizing  NBS  technical  staff  with  key  DoD  logistic 
functions  and  CALS  demonstration  projects, 

o  briefing  DoD  personnel,  contractors,  and  other 
interested  parties  on  Federal,  national,  and 
international  standardization  efforts  that  are  expected 
to  support  CALS  objectives, 

o  identifying  a  preliminary  set  of  standards  required  for 
data  interchange  in  support  of  CALS,  and 

o  developing  reports  on  the  four  broad  categories  of 
standards  required  to  support  the  interchange  of  CALS 
digitized  technical  information:  (1)  product  definition 
data,  (2)  graphics,  (3)  text,  and  (4)  data  management. 

As  a  result  of  these  efforts,  NBS  made  a  preliminary 
identification  of  several  high-priority  standards  implementations 
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needed  for  CALS  data  Interchange  and  access.^  Building  on 
knowledge  and  experience  gained  during  FY86,  NBS  focused  on  the 
following  activities  in  FY87:  developing  a  CALS  Framework, 
Development  Plan  and  Core  Requirements  Package;  providing 
technical  support  for  standards  development  and  implementation; 
and  conducting  workshops  and  meetings  to  promote  dialogue  with 
the  Services,  the  Defense  Logistics  Agency,  and  industry. 

A  major  FY87  thrust  was  the  completion  of  initial  docvunentation 
of  the  high-priority  standards  required  in  the  CALS  environment. 
Some  of  these  standards  (e.g.,  SGML,  IGES)  required  tailoring  or 
enhancement.  Other  standards  required  a  "push"  (e.g.,  CGEM)  for 
their  development  in  a  timely  fashion.  These  four  volumes  are  a 
collection  of  the  final  reports  presented  to  the  CALS  Policy 
Office.^  The  collection  is  divided  as  follows: 

VOLUME  1: 

Text 

Evaluation  of  Text  Interchange  Methods 

Plan  for  Conformance  Testing  for  DoD  Implementation  of  SGML 

Guidelines  for  the  Development  of  Tags  for  S(^(L 

The  NBS  FIPS  -  SGML  Validation  Suite 

The  NBS  FIPS  -  SGML  Reference  Parser 

Using  SGML  -  Application  Guidelines 

ODA/ODIF  Implementation  Agreement  a  Document  Application 
Profile 

Data  Management 

CALS  Report  on  Data  Management  Standards 

Supporting  Logistic  Suppozt  Analysis  (LSA)  Using  the 
Information  Resource  Dictionary  System  (IRDS) 


Media 

ICST  Recommendations  on  Optical  Disks  and  Interface 
Requirements  for  Planned  EDMICS  Procure:aent ,  Final 
Report 


Kemmerer,  S.,  Editor,  "Final  NBS  Report  for  CALS, 
FYSe,”  U.S.  Department  of  Commerce,  National  Bureau  of 
Standards,  NBSIR  87-3566,  May  1987. 

The  publishing  of  this  collection  of  reports  does  not 
imply  the  CALS  Policy  Office  has  endorsed  the 
conclusions  and  recommendations  presented. 
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Raster  Compression 

Report  on  Raster  Graphics 

Tiled  Raster  Interchange  Format,  TRIP  Version  1.0,  Rev.  1.2 
Conformance  Testing 

NBS  Plan  for  Validation  (Conformance  Testing)  of  Computer 
Products  In  Support  of  the  CALS  Progreun 


VOLOME  2: 

Graphics 

Raster-to-Vector  Conversion:  A  State-of~the-Art  Assessment 
Development  of  CGM  Validation  Routines 
CALS  Application  Profile  for  CGM 

CALS  Requirements  Reflected  In  the  Extended  CGM  (CGEM) 
Standards  Effort 

A  Reference  Implementation  for  CGM,  Functional  Requirements 
and  Conceptual  Design 

IGES  to  CGM  Translator  Design  Specification 

VOLDMB  3: 

Graphics 

CGM  Registration  For  CALS  Requirements 

VOLOME  4: 

Product  Data 

Guidelines  for  Testing  IGES  Translators 
Guidelines  for  IGES  Application  Subsets 
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The  following  are  additional  deliverables  conpleted  by  NBS  during 
FY87  but  under  separate  cover.  They  are  availedsle  through  the 
CALS  Policy  Office. 

CALS  Core  Requirements,  Phase  I.O 

CALS  Framework' 

CALS  Progreun  Integration  of  Logistic  Support  Analysis  and 
Relied)illty  and  Maintainability  Data  DelivereUbles 

CALS  Current  State  of  Digital  Technology  (Phase  1.0} 

CALS  Workshop  Proceedings: 

Graphics  Data  Interface  for  Engineering  Design  and  Technical 
Pviblication  Systems  (January  13/14) 

Introduction  to  the  Core  Requirements  Package  (April  23) 

MILSTD-1840A,  Automated  Interchange  of  Technical  Information 

MILSPEC-D-28000,  Digital  Representation  for  Communication  of 
Product  Data:  Application  Subsets 

MILSPEC-M-28001,  Manuals,  Technical:  Markup  Requirements  and 

Generic  Style  Specification  for  Electronic  Printed  Output 
and  Exchange 
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I.  PURPOSE 


The  purpose  is  to  register  extensions  to  the  Computer  Graphics  Metafile  (CGM)  standard  through 
the  American  National  Standards  Institute  (ANSI)  and  International  Standards  Organization  (ISO) 
processes  to  meet  CALS  requirements,  to  ensure  that  all  geometric  objects  which  are  displayed 
graphically  in  CALS  can  be  represented  by  the  CGM.  (Task  2.22.1.2) 

n.  BACKGROUND 

The  extensions  necessary  to  allow  the  CGM  to  properly  support  CALS  requirements  for  data 
interchange  in  the  areas  of  Technical  Publishing,  Administrative  Publishing,  and  Technical 
Drawings  were  derived  fom  applicable  standards,  commercial  product  descriptions,  and  CALS 
program  documents.  The  simplest  extensions  are  described  as  registered  lin<*fypes.  hatchstyles. 
and  markertypcs.  Such  extensions  add  no  additional  "functionality  ”  to  the  CGM.  More  complex 
extensions  are  described  in  the  form  of  the  Graphical  Drawing  Primitives  (GDPs)  and  Escapes 
necessary  for  their  implementation.  NBS/ICST  concludes  that  the  general  framework  of  the  CGM 
is  adequate  to  support  CALS  requirements,  but  that  a  large  number  of  extension.s-  ome  involving 
significant  new  concepts-are  required.  The  effon  expended  under  this  year's  SOW,  although  very 
comprehensive,  addresses  only  a  small  portion  of  the  CGM  extensions  which  should  be  registered 
for  (TALS  use.  This  report  does  indicate  what  should  be  done  in  follow  up  work.  This  will  be 
discussed  in  Section  V  of  the  report. 

1.0  Overview  of  Computer  Graphics  Standards 

For  completeness  and  to  allow  comparison  with  CALS  requirements,  the  output  facilities  of  the 
family  of  ISO/ANSI  computer  graphics  standards — induing  the  CGM — are  described  in  this 
paragraph.  This  material  is  drawn  from  [1]. 

1.1  Output  Primitives 

Computer  ^phics  standards  provide  six  output  primitives:  one  line-primitive,  one  point-primitive, 
one  text-primitive,  two  raster-primitives  and  one  general  purpose  primitive  serving  a*^  an  entry  point 
for  specific  workstation  capabilities  and  as  a  mechanism  for  extending  die  standards  in  a  'standard 
way." 

POLYLINE  -  generates  a  set  of  straight  lines  connecting  a  given  point  sequence. 

POLYMARKER  -  generates  symbols  of  some  type  centered  at  given  positions.  The  symbols  are 
called  markers;  these  are  glyphs  (symbolic  characters)  with  specified  appearances  which  are  used  to 
identify  a  set  of  locations. 

TEXT  -  generates  a  character  string  at  a  given  position. 

FILL  AREA  -  generates  a  polygon  which  may  be  hollow  or  filled  with  a  uniform  color,  a  pattern, 
or  a  hatch  style. 

CELL  ARRAY  -  generates  an  array  of  rectangular  cells  with  individual  colors.  This  is  a 
generalization  of  an  array  of  pixels  on  a  raster  device.  However,  the  cells  of  this  primitive  need  not 
map  one-to-one  with  the  pixels  defined  by  the  display  hardware. 

GENERALIZED  DRAWING  PRIMITIVE  (GDP)  -  addresses  special  geometrical  output 
capabilities  such  as  the  drawing  of  spline  curves,  circular  arcs,  and  elliptic  arcs.  The  objects  are 
characterized  by  an  identifier,  a  set  of  points  and  additional  data.  All  transformations  are  apr'ied  to 
the  points  but  the  interpretation  is  left  to  the  workstation. 
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1.2  Output  Primitive  Attributes 


Tabic  1  gives,  for  every  type  of  primitive,  the  set  of  attributes  that  control  their  appearance.  The 
attributes  describe  the  following  aspects  of  output  primitives. 

Pick  identifier  -  A  number  assigned  to  individual  output  primidves  within  a  segment  and 
returned  by  the  pick  device.  The  same  pick  identifier  can  be  assigned  to  different  output  primidves. 
These  no  not  apply  to  the  CGM. 

Linetype  -  Linetypes  are  used  to  distinguish  different  styles  of  lines.  A  line  may  be,  for  example, 
solid,  dashed,  or  dashed-dotted. 

Linewidth  scale  factor  -  The  actual  width  of  a  line  is  given  by  a  normal  linewidth  muldplied  by 
the  linewidth  scale  factor. 

Color  -  The  color  is  specified  by  the  red-,  green-,  and  blue-intensides  defining  a  particular  color 
(RGB-values). 

Marker  type  -  The  marker  type  is  a  number  specifying  the  particular  glyph  used  for  idendficadon 
of  the  polymarker  positions. 

Marker  size  scale  factor  -  The  actual  marka*  size  of  a  line  is  given  by  a  nominal  marker  size 
muldplied  by  the  marker  size  scale  factor. 

Text  font  -  The  text  font  is  a  number  selecting  one  representation  for  the  text  string  characters  out 
of  the  possibilities  present  on  a  workstation. 

Text  precision  -  An  attribute  describing  the  fidelity  with  which  character  position,  character  size, 
character  orientation,  and  character  font  of  text  output  match  those  requested  by  an  application.  In 
order  of  increasing  fidelity,  the  precisions  are  string,  character,  and  stroke. 

Character  height  -  The  vertical  extent  of  a  character. 

Character  up  vector  -  The  "UP"  -direction  of  a  character. 

Character  expansion  factor  -  The  deviation  of  the  width/height-ratio  of  a  character  from  the 
ratio  defined  by  the  text  font  designer. 

Text  path  -  The  writing  direction  of  the  character  sequence.  The  normal  path  is  "right,"  i.e.,  the 
text  you  are  reading  is  written  from  left  to  right.  The  standards  allow  the  text  path  values;  left,  up, 
and  down  also. 

Character  spacing  -  Space  to  be  inserted  between  adjacent  characters  of  a  text  string  in  addition 
to  the  space  defined  by  the  font  designer. 

Character  alignment  -  A  text  attribute  describing  how  the  text  string  is  positioned  relative  to  the 
reference  point  of  the  text  primitive  (e.g.,  left  aligned,  centered). 

Interior  style  -  The  interior  style  used  to  determine  in  what  style  an  area  should  be  filled.  It  has 
one  of  the  values:  hollow,  solid,  pattern,  or  hatch. 

Pattern  size  -  The  pattern  size  specifies  the  size  of  the  basic  panem  rectangle. 
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Pattern  reference  point  -  The  pattern  reference  point  specifies  the  origin  of  the  basic  pattern 
rectangle.  The  lower  left  comer  of  the  rectangle  is  placed  at  the  reference  point.  Then  the  pattern  is 
repeated  in  both  directions  until  the  whole  area  is  fWed. 

Pattern  array  -  A  pattern  is  defined  by  an  array  of  rectangular  cells,  each  cell  having  a  color 
assigned  to  it.  These  values  are  used  to  assign  colors  to  the  basic  pattern  rectangle  and  to  all 
replications  of  it. 

Hatch  style  -  Hatching  is  specified  by  a  number  selecting  one  hatch  style. 


Primitive 


Attributes 


POLYLINE 


POLYMARKER 


TEXT 


FILL  AREA 


CELL  ARRAY 

GENERALIZED 

DRAWING 

PRIMmVE 


PICK  IDENTIFIER 
LINEWIDTH  SCALE  FACTOR 

PICK  IDENTIFIER 
MARKER  SIZE  SCALE  FACTOR 

PICK  IDEN  TIFIER 
CHARACTER  HEIGHT 
CHARACTER  UP  VECTOR 
CHARACTER  EXPANSION  FACTOR 
TEXT  PATH 
CHARACTER  SPACING 

PICK  IDENT  IFIER 
PATTFRN  ST7F 

PATTERN  REFERENCE  POINT 
PATTERN  ARRAY 

PICK  IDENTIFIER 

PICK  IDENTIFIER 
dependent  on  the  type  of  GDP 


UNETYPE 

COLOR 

MARKER  TYPE 
COLOR 

TEXT  FONT 
TEXT  PRECISION 
COLOR 

TEXT  ALIGNMENT 


INTERIOR  STYLE 
HATCH  STYLE 
COLOR 


COLOR 


Table  1.  Output  Primitive  Attributes 
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2.0  Registration  of  Graphical  Items 

The  purpose  of  this  paragraph  is  to  define  the  framework  through  which  graphics  standards  are 
extended  by  the  procedure  called  registration.  (Registradon  procedures  do  not  assign  values 
which  are  defined  as  being  workstation-  or  implementation-dependent.)  Registration  applies  to  the 
registration  of  individual  items  within  the  following  classes  of  graphical  items  as  reserved  for 
registration  in  computer  graphics  standards; 

a)  Generalized  drawing  primitive  (GDP)  function  definitions; 

b)  Graphical  escape  function  definitions; 

c)  Linetypes; 

d)  Markertypes; 

e)  Hatchstyles; 

f)  Textfont  appearance; 

g)  Prompt  and  echo  type  definititMis  (for  graphical  interaction— does  not  apply  to  the  CGM); 

h)  Error  messages. 

Linetype,  markertype,  and  hatchs^le  re^stration  adds  additional  types  and  styles  to  supplement 
those  (kfined  in  the  standards.  Their  definition  is  straightforward.  Textfont  appearance  registers  the 
identifiers  through  which  text  fonts  are  accessed  by  graphics  standards.  GDP  and  Escape 
registration  are  the  mechanisms  through  which  additional  functionality  is  added  to  a  graphics 
standard.  For  example,  curves  can  be  ad^  through  GDP  re^tration  and  additional  line  attributes 
-  such  as  endcaps— can  be  added  through  Escape  registration.  Since  this  report  addresses  only 
CGM  extensions.  Prompt  and  Echo  Type  defmition  are  not  considered.  Error  messages  are 
registered  as  necessary  to  support  register^  GDPs  and  Escapes. 

2.1  Registration  in  the  CGM  Standard 

The  CGM  standard  (ANSI  X3. 122- 1986  or  FIPS  128)  describes  registration  in  this  way. 

For  certain  elements,  the  CGM  defines  value  of  range  of  parameters  as  being  reserved  for 
registration.  The  meanings  of  these  values  will  be  defined  using  the  established  procedures 
of  the  ISO  International  Registration  AuthOTity  for  Graphical  Items.  These  procedures  do  not 
apply  to  values  and  value  ranges  defined  as  being  reserved  for  implementation-dependent  or 
pnvate  use;  these  values  and  ranges  are  not  standardized. 

Applications  therefore,  shall  not  use  parameter  values  in  the  reserved  ranges  for 
implementation-dependent  or  private  use.  Those  elements  that  will  be  affected  by  registration 
of  graphical  items  are: 

a)  LINE  TYPE; 

b)  MARKERTYPE; 

c)  HATCH  STYLE; 

d)  EDGE  TYPE; 

e)  FONT  LIST  (allows  the  selection  of  named  fonts  via  a  font  index); 

f)  GENERALIZED  DRAWING  PRIMITIVE; 

g)  ESCAPE. 
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Registration  of  character  sets  for  use  with  the  CHARACTER  SET  LIST  element  is 
according  to  the  procedures  established  by  ISO  2375,  Character  Set  Registration. 

The  COM  includes  the  following  "built-in"  values  for  items  subjea  to  registration: 

1)  LINE  TYPE: 

1.  solid 

2.  dash 

3.  dot 

4.  dash-dot 

5.  dash-dot-dot 

2)  MARKER  TYPE: 

1.  dot  (.) 

2.  plus  (+) 

3.  asterisk  (*) 

4.  circle  (o) 

5.  cross  (x) 

3)  HATCH  TYPE  (called  HATCH  STYLE  in  the  above  extract  firom  the  COM  standard): 

1.  horizontal  equally  spaced  parallel  lines 

2.  vertical  equally  spa<^  pa^lel  lines 

3.  positive  slope  equally  spaced  parallel  lines 

4.  negative  slope  equally  spaced  parallel  lines 

5.  hotizontal/vertic^  crosshatch 

6.  positive  slope/negative  slope  crosshatch 

4)  EDGE  TYPE  (the  built-in  ones  correspond  directly  to  line  types): 

1.  solid 

2.  dash 

3.  dot 

4.  dash-dot 

5.  dash-dot-dot 

5)  Text  Fonts: 
none 

6)  GENERALIZED  DRAWING  PRIMITIVE: 
none 

7)  ESCAPE: 
none 

It  may  be  necessary  to  extend  the  CGM  by  adding  functions  that  cannot  be  accommodated  in  the 
restricted  format  of  registered  items.  These  extensions  can  be  done  by  adding  external  elements. 
The  CGM  standard  describes  GDPs,  Escapes  and  External  elements  in  this  way: 

Generalized  drawing  primitives 

The  GENERALIZED  DRAWING  PRIMITIVE  (GDP)  is  a  graphical  printitive  element  that 
may  be  used  to  access  device  (or  implementation)  specific  graphical  primitives  that  are  not 
accessed  by  the  standardized  elements. 
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Escape  elements 


ESCAPE  elements  describe  device-  or  system-dependent  data  in  the  COM.  ESCAPEs  may 
be  included  in  the  metafile  at  the  discretion  of  the  user,  but  direct  effects  and  side  effects  of 
the  use  of  nonstandardized  elements  are  beyond  the  scope  of  this  standard.  This  standard 
imposes  no  constraints  on  the  functional  intent  or  content  of  data  passed  by  the  ESCAPE 
mechanism. 


External  elements 

External  elements  communicate  information  not  directly  related  to  the  generation  of  a 
graphical  image.  They  may  appear  anywhere  in  the  CGM. 

The  APPLICATION  DATA  element  allows  applications  to  store  and  access  private  data.  This 
element  is  not  a  graphical  element  and  its  interpretation  will  have  no  effect  on  any  picture 
produced  by  an  interpreter. 

For  specification  of  non-standardized  graphical  effects,  the  ESCAPE  and  GENERALIZED 
DRAWING  PRIMITIVE  elements  are  provided.  These  elements  may  have  an  effect  on  the 
picture  {xoduced  by  an  interpreter. 

2.2  Why  Registration  for  the  CGM  Alone  is  Insufficient 

The  CGM  standard  (deliberately)  do^s  not  standardize  the  actions  of  metafile  generators  or 
interpreters.  However,  since  metafiles  are  to  be  used  in  a  fixed  environment — such  as  the  DoD 
CALS  program — to  transfer  picture  data,  then  the  action  of  both  metafile  generamrs  and  interpreters 
must  be  precisely  defined.  This  is  done  by  the  definition  of  application  profiles.  Such  a  profile 
for  CALS  is  being  developed  by  NBS/ICST. 

Also,  graphical  items  must  be  registered  for  use  not  only  by  the  CGM  but  by  all  (applicable) 
standa^s.  Requirements  for  simple  extensions  such  as  linetypes,  maikertypes,  and  hatchstyles  are 
similar  in  all  graphics  standards.  However,  the  application  program  interface  standards  have  more 
rigorous  requirements  for  registered  Escape  and  GDP  elements.  This  is  illustrated  by  the 
following  extracts  from  the  Graphical  Kernel  System  (GKS)  standard  (FIPS  120,  ISO 
7942-1985),  which  should  be  connasted  to  those  given  in  Section  2.1  from  the  CGM: 

Escape 

Parameters: 

In  specific  escape  function  identification 
In  escape  input  data  record 
(hit  escape  output  data  record 

Effect:  The  specified  non-standard  speciric  escape  function  is  invoked.  The 
form  of  the  escape  data  record  and  which  of  them  are  used  may  vary  for  different 
functions.  Also  the  GKS  states  allowing  the  invocation  of  a  specific  escape  function  may  be 
restricted.  The  following  rules  govern  the  definition  of  a  new  specific  escape  function: 

a)  the  GKS  design  concept  (see  Section  0  -  introduction) 

b)  the  GKS  state  lists  are  not  altered. 

c)  the  function  does  not  generate  geometrical  output 

d)  any  side  effects  are  well  documented. 
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Specific  escape  functions  may  apply  to  more  than  one  workstation,  for  example,  all  open 
workstations  or  all  active  workstations.  The  escape  input  data  record  can  include  a 
workstation  identifier  where  this  is  required. 

Note:  Examples  of  specific  escape  functions  anticipated  at  present  are: 

a)  suppon  of  raster  devices  allowing  the  display  of  more  than  one  fiame  buffer, 

b)  use  of  raster  or  hardware  to  manipulate  data  previously  output  by  cell  array. 

Where  the  specific  escape  function  identification  is  bound  to  an  integer  in  a  programming 
lan^age  specific  escape  function  identifications  greater  than  0  are  received  for 
registration  or  future  standardization  and  specific  escape  function  identifications  less 
than  0  are  implementation  dependent 

Specific  escape  function  identifications  are  registered  in  the  ISO  International  Register  of 
Graphical  Items,  which  is  maintained  by  the  Registration  Authority.  When  a  specific 
escape  function  has  been  approved  by  the  ISO  Working  Group  on  Computer  Graphics, 
die  specific  escape  function  identification  will  be  assigned  to  the  Registratitm  Authority. 

Generalized  drawing  primitive  (GDP) 

Parameters: 

In  number  of  points 
In  points 
In  GDP  identifier 
In  GDP  data  record 

Effect:  A  Generalized  £>rawing  Primitive  (GDP)  of  the  type  indicated  by  the  GDP  identifier  is 
generated  on  the  basis  of  the  ^ven  points  and  the  GDP  data  record.  The  current  values  of  the 
entities  in  the  GKS  state  list  ...  for  the  set  of  polyline,  polymarker,  text  or  fill  area 
attributes  are  bound  to  the  primitive.  These  attributes  are  listed  in  ...  When  the  GDP 
generates  output  at  the  workstation,  zero  or  more  of  the  sets  of  attributes  are  used.  These  are 
the  sets  of  attributes  most  appropriate  for  the  specified  GDP  function  and  are  selected  for  the 

GDP  as  part  of  the  definition  of  the  GDP.  (They  are  defined  in  the  workstation  description 
table). 

Note:  The  parameters  are  transmined  to  the  workstation  and  interpreted  in  a  workstation 
dependent  way  that  special  capabilities  of  the  workstation  can  be  addressed.  Even  if 
errors  occur,  the  GDP  is  display^  on  all  active  workstations  capable  of  doing  so.  For 
example,  some  of  the  parameters  anticipated  at  present  are: 

a)  circle  points  given  are  centre,  peripheral  point, 

b)  circular  arc  points  are  centre,  stan  point,  end  point  to  be  connected  anticlockwise  in 
world  coordinates, 

c)  elipse  points  given  are  2  focal  points,  peripheral  point, 

d)  elliptic  arc  points  given  are  2  focal  points,  start  point,  end  point  to  be  connected 
anticlockwise  is  world  coordinates, 

e)  interpolating  curve  (for  example,  spline)  points  given  are  interpolated. 

The  recommended  set  of  attributes  to  use  for  the  above  GDP  examples  would  be  the  polyline 
attributes. 
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It  should  be  emphasized  that  the  points,  specified  as  parameters,  are  transformed  by  GKS 
after  the  interpolation  of  the  points  (as  defining  say,  a  spline  curve  or  circle)  is  performed 
by  the  active  workstation.  For  example,  a  GDP,  which  defines  a  circle,  would  appear  as  an 
ellipse  when  the  transformation  has  differential  scaling  for  the  two  axes.  Each  specific  GDP 
definition  detines  how  the  transformation  is  applied  to  both  the  points  and  the  shape  of  the 
GDP.  Though  the  points  cannot  be  clipped,  the  resulting  ouqjut  of  the  GDP  is  clipped 
against  the  clipping  rectangle,  if  the  "clipping  indicator"  entry  is  the  GKS  state  list  is  CLIP, 
and  the  workstation  window.  If  a  specific  GDP  is  available  on  a  workstation  but  is  unable  to 
be  generated  because  the  current  transformations  or  clipping  rectangle  are  such  that  the 
preceding  conditions  would  be  violated,  an  error  occurs. 

The  GDP  data  record  attribute  list  may  contain  additional  data  for  each  point  (for  example, 
venex  order  for  splines)  which  remain  untransformed.  These  have  to  be  defined  for  a 
specific  GDP.  In  defining  a  new  GDP,  the  GKS  design  concepts  (see  Section  0)  are  not 
violated.  The  set  of  gene^zed  drawing  primitives  implemented  on  a  workstation  may  be 
empty. 

Where  the  GDP  identifier  is  bound  to  an  integer  in  a  progranmung  language,  GDP  identifiers 
greater  than  0  are  reserved  for  registration  or  future  standardization  and  GDP  identifiers  less 
than  0  are  implementation  dependent 

GDP  identifiers  are  registered  in  the  ISO  Register  of  Graphical  Items,  which  is  maintained  by 
the  Registration  Authority.  When  a  GDP  has  been  approved  by  the  ISO  Working  Group  on 
Computer  Graphics,  the  GDP  will  be  assigned  by  the  Registration  Authority. 


2J  The  Required  Approach  for  CALS  Registration 

Based  on  the  above  discussion,  when  writing  actual  registration  proposals  for  graphical  items 
required  for  CALS,  the  following  must  be  done: 

1)  define  how  the  item  is  implemented  in  all  applicable  graphics  standards; 

2)  develop  all  necessary  language  bindings; 

3)  precisely  define  the  semantics  of  the  item. 

Registration  proposals  developed  contain  a  semantic  specification  that  is  complete  and  precise 
enough  to  define  the  required  actions  by  metafile  generators  and  interpreters.  Portions  of  these 
descriptions  may  prove  too  explicit  to  be  approved  by  the  required  ANSI  and  ISO  standards 
committees.  (These  committees  are  accustom^  to  specifymg  items  as  loosely  as  possible  to  allow 
as  many  implementations  as  possible  to  conform.)  In  this  case,  some  material  may  need  to  be 
moved  tiom  the  registration  proposal  to  the  CALS  application  profile.  In  addition,  some  extensions 
may  only  be  achievable  tluough  the  use  of  the  CGM  External  Data  element 
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3.0  Applicable  Standards 

The  standards  listed  in  this  section  were  identified  as  being  applicable  to  technical  drawings  and 
automated  (technical  and  administrative)  publishing.  Drawing  and  drafting  standards  were  included 
in  the  list  since  they  are  the  best  source  of  information  on  the  "graphical  presentation"  requirements 
for  engineering  drawings.  Product  data  standards  were  included  since  they  are  often  (mistakenly) 
used  for  picture  transfer  purposes  and,  consequently,  contain  features  relating  to  the  "i^sentation" 
requirements  for  such  data.  The  FIPS,  ANSI  and  ISO  standards  in  the  areas  of  graphics  standards 
and  product  data  definition  are  not  repeated  here,  since  they  are  adequately  documented  in  last 
year's  final  report. 

Technical  publishing 

MIL-M-38784B  -  Manuals,  Techiucal:  General  Style  and  pOTmat  Requirements 

Description  of  drawing  forms 

ANSI  Y14. 1  -  Drawing  Sheet  Size  and  Format  (1980) 

ANSI  Y14.2M  -  Line  Conventions  and  Lettering  (1979) 

Lists:  purpose,  classification,  and  preparation 

ANSI  Y14.1-1980-  Drawing,  Sheet  Size  and  Format 
ANSI  Y14.34M-1982  •  Parts  lists.  Date  Lists  and  Index  Lists 

ANSI  Y32. 16  •  Reference  Designations  for  Electrical  and  Electronic  Parts  and  Equipment 

DoD-D-  lOOOB  Drawings,  Engineering  and  Associated  Lists 


Printed  board  drafting  practice 


MIL-STD-100 

MIL-STD-275 

MIL-STD-429 

MIL-STD-1494 


Engineering  Drawing  Practices 
Printed  Wiring  for  Electronic  Equipment 
Printed- Wiring  and  Printed-Circuit  Terms  and  Definitions 
Multilayer  Printed  Wiring  Boards  for  Electronic  Equipment 


ANSIY14.S  -  Dimensioning  and  Tolerancing 

ANSI  Y32. 16  -  Reference  Designations  for  Electrical  and  Electronic  Parts  and  Equipment 


IPC-T-50 

IPC-D-310 

IPC-D-350 

IPC-D-390 

IPC-CM-770 


Terms  and  Definitions 

Suggested  Guidelines  for  Artwork  Generation  and  Measurement  Techniques 
for  Mnted  Circuits 

Printed  Board  Description  in  Digital  Form 

Guidelines  for  Design  Layout  and  Artwork  Generation  on  Computer 
Automated  Equipment  for  Ptmted  Wiring 
Component  Mounting  Guidelines 


MIL-D-8510 

MIL-I-46058 

MIL-P-55110 


Drawings,  Undimensioned,  Reproducible,  Photographies  and  Contact: 
Preparation  of 

Insulating  Compound,  Electrical  for  Coating  Printed  Circuit  Assemblies 
Printed  Wire  Boards 
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Line  conventions  and  lettering;  signs  and  symbols 

ANSI  Y14.2M-1979  -  Line  Conventions  and  Lettering 
ANSI  Y10.3  -  Quantities  Used  in  Mechanics  of  Solids:  Letter  Symbols  for 

ANSIY10.20  -  Mathematic  Signs  and  Symbols  for  Used  in  Physical  Sciences  and 

Technology  (include  supplement  ANSI  Y10.20a  1975) 

Drawing  preparation  for  microfilming 


ANSIY14.1  -  Drawing  Sheet  Size  and  Format 
ANSI  Y14.2M  •  Line  Conventions  and  Lettering 

NMA  -  MS  1(X)-1971  Glossary  of  Micrographics  Terms 

MIL-M-9868D  Microfilming  of  Engineering  Documents 


Other  drawing  practices 

ANSI  Y14.7. 1  -  Gear  Drawing  Standards — Part  1  for  Spur,  Helical,  Double,  and  Rack 

ANSI  Y14.7.2  •  Gear  and  Spline  Drawing  Standards — Pan  2,  Bevel  and  Hypoid  Gears 

ANSIY14.17  '  Fluid  Power  Diagrauns 

ANSI  Y14.13M  •  Engineering  Drawing  and  Related  Documentation  Practices — Mechanical 
Springs 

Dimensioning  and  tolerancing  (general  dimensions) 

ANSI  Y14.3  -  Multi  and  Sectional  View  Drawings 

ANSIY14.5M  -  Dimensioning  and  Tolerancing 

ANSIY14.6  *  Screw  Thread  Representation,  Engineering  Drawing  and  Related 
Documentation  Practice 


Reference  designations  for  electrical  parts  and  equipment;  electrical  diagrams 


ANSI  Y32.16 

ANSI  Y32.2 
ANSI  Y14.15 

ANSI  Y14. 15b 


1975  Reference  Designations  for  Electrical  and  Electronics  Pans  and 
Equipment 

1^5  Graphic  Symbols  for  Electronic  Diagrams 

Electrical  and  Electronics  Diagrams  (Includes  supplements  ANSI  Y 14. 15a 
and  Y14.15b  1973) 

Electrical  and  Electronics  Diagrams  (supplement  to  ANSI  Y14.15  1966) 


Note:  These  standards  have  been  accepted  for  use  by  the  Department  of  Defense. 


MIL-STD-15-2  -  Electrical  Wiring  Equipment  Symbols  for  Ships’ Plans  Pan  2 


Surface  texture 

ANSI-B46. 1-1978  -  Surface  Texture 
ANSI-Y  14.36- 1978  -  Surface  Texture  Symbols 
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Abbreviations  -  for  use  on  drawings  and  technical  documentation 
ANSI  Y  1.1  -  Abbreviations 

MIL-STD  12  -  Abbreviations  for  Use  on  Drawings,  Specifications,  Standards,  and 

Technical  Documents 


Graphic  symbols  for  metal  joining  and  nondestructive  testing  symbols  (welding) 


AWS  A2.4-76  -  Symbols  for  Welding  and  Nondestructive  Testing. 

MIL-STD-25B  -  Ship  Structural  Symbols  for  Use  on  Ship  Drawings 
Specification  practices 


MIL-STD-490 

\UL-S-83490 

DOD-STD-100 

MIL-STD-961 

MIL-STD-1679 

DSM  4120.3M 


Specification  Practices 
Specifications,  Types  and  Forms 
Engineering  Drawing  Practices 

Outline  of  Forms  and  Instructions  for  the  Presentation  of  Specification 
Weapon  Systems  IDevelopment  (Navy) 

Standardization  Policies  Procedures  and  Instructions 


ISI  metric  practice 


ASTM  E380  -  Standard  for  Metric  Practices 

DOD-STD-1476  -  Metric  System,  Application  in  New  Design 


Production  identification 


MIL-STD-130 
MIL-P-15024 
MIL- 19834 

MIL-P-83497 


Identification  Marking  of  US  Military  Property 
Plates,  Tags,  and  Bar^  for  Mentification  of  ^uipment 
Plates,  Identification  or  Instruction,  Metal  FoU,  Adhesive  Backed,  General 
Specifications  for 

l4ocedures  for  Preparation  of  Progranuned  Tapes  and  Cards 


Communication  of  product  data 

ANSI  Y  14.26.3  -  Dictionary  of  Terms  for  Computer-aided  Preparation  of  Product  Definition 

Date  (including  Engineering  Drawings) 

ANSI  Y14.26  -  Engineering  Drawing  and  Related  Documentation  Practices — Digital 

Representation  for  Communication  of  Produa  Definition  Data 

DoD/CALS  specific  standards 

Draft  MIL-STD- 1840A  -  Automated  Interchange  of  Technical  Information 
DOD-D-(IGES)  -  Digital  Representation  for  Communication  of  Product  Data:  Application 
Subsets 
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4.0  Reference  Model 


For  purposes  of  this  task,  a  very  simple  reference  model  has  been  adopted  to  define  how  the  CGM 
is  used  in  technical  drawing  pn^ucdon  and  publishing  applications. 

For  the  purposes  of  this  work,  it  is  assumed  that  the  CGM  will  be  used  in  the  following  manner  in 
CALS: 

1 )  CGM  pictures  will  be  used  to  transfer  engineering  drawings. 

2)  CGM  pictures  will  be  used  to  transfer  pages  of  technical  publications  which  contain 
both  text  and  graphics;  the  extensions  being  ^fined  herein  will  allow  the  CGM  alone  to  be 
used  for  transferring  the  content  of  document  pages — text,  geometric  graphics,  and  image 
(raster)  graphics.  The  CGM  may  also  be  used  to  transfer  pictures  which  are  then  embedded  in 
documents  by  some  process  outside  the  scope  of  this  study. 


No  asstimpdons  were  made  in  the  following  areas: 

1)  The  manner  in  which  graphical  metafiles  are  transferred. 

2)  The  embedding  of  CGM  content  in  documents  defined  in  other  standards  (  for  example, 
ODA  and  SGML). 

3)  The  manner  in  which  descriptions  of  externally  defined  items  are  made  available  to  a  CGM 
interpreter. 

4)  Transfer  of  "processible"  product  definition  data  or  "processible-form”  office  documents. 
(It  is  assumed  IGES  and/or  ODA/ODEF  are  used  in  these  cases). 
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in.  DISCUSSION 


1.0  Technical  and  Administrative  Publishing 
1.1  Introduction 

It  is  widely  recognized  that  computer  graphics  standards,  CGM  in  particular,  will  need  to  be 
extended  to  prepay  support  publishing  in  the  CALS  environmenL  Such  extensions  will  be  initially 
developed  in  the  form  of  GDPs  and  Escapes  and  the  "folded  into"  the  standards  during  their  next 
revision  cycles. 

The  following  liaison  statement  (between  the  two  relevant  standards  bodies)  from  ASC  X3H3 
(Computer  Graphics)  to  ASC  X3V1  (Office  Systems)  summarizes  some  of  these  changes; 

Liaison  Statement  to  X3V1  TG8  Concerning  TPM  (Text  Presentation  Metafile) 
User  Requirements  (X3H3/87-31) 


1 .  Rapid  soft  copy  display  of  formatted  composite  documents. 

2.  Use  of  intemationallv  standardized  coIot  naodels  in  interchange. 

3.  Use  of  standard  methods  for  image  comi^ssion. 

4.  General  fill  boundary  specification. 

5  Wide  lines  with  joint  and  end  features,  and  patterns  with  anchoring. 

6.  Curves,  including  conics  and  Bezier  curves. 

7.  General  clip  boundary. 

X3H3  would  like  to  work  with  the  TPM  developers  on  graphics  aspects  to  achieve  two  goals: 

1 .  Any  functionality  in  TPM  which  is  close  to  functionality  in  GKS  or  CGM  should  be 
identical. 

2.  Any  graphic  functionality  required  by  TPM  but  not  present  in  CGM  should  be  developed 
jointly  so  that  it  can  be  used  compatibly  by  existing  and  future  graphics  and  office  systems 
standards. 

Subsequent  sections  describe  first  the  methodology  by  which  extensions  in  the  publishing  area 
were  determined,  and  then  the  general  features  that  must  be  added  to  the  CGM.  These  general 
features  are  given  by  way  of  example  of  current  proprietary  products. 

1.2  Required  Capabilities  CGM  Must  Be  Extended  to  Meet 

In  the  absence  of  standards  in  this  area  (the  Text  Presentation  Metafile  under  development  in  X3V1 
will  not  be  available — even  in  draft  form — until  late  1987),  the  features  of  the  most  widely  used 
commercial  products  have  been  used  to  define  the  required  capabilities.  In  particular,  the  PostScript 
Page  Description  Language  [5,6]  of  Adobe  Systems  has  been  selected  to  provide  a  baseline  set  of 
capabilities.  In  some  cases,  features  from  the  Interpress  Page  Description  Language  [4]  of  Xerox 
Corporation  have  been  used  instead  of  or  in  place  of  those  in  PostScript 
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Defining  required  capabilities  in  the  publishing  area  is  more  difficult  than  for  engineering  drawing, 
since  format  and  presentation  are  determined  more  by  artistic  considerations  than  slavish  adherence 
to  format  standa^.  MIL-M-38784B  contains  requirements  for  high-level  formatting  and  no 
"presentation”  requirements.  Unless  noted,  the  capabilities  discussed  below  have  been  made  into 
registration  proposals,  and  can  be  found  in  the  Recommendations  section. 

1.2.1  Lines 

"Lines"  in  PostScript  are  drawn  through  a  rwo-step  process.  First,  a  path  is  constructed, 
corresponding  to  the  line  to  be  drawn.  This  is  done  by  a  sequence  of  moveto  and  iineto 
operators.  (Relative  operators,  or  curve  operators  can  be  interspersed-  Appendix  B  provides  a  list 
of  all  PostScript  operators,  and  detailed  descriptions  of  the  ones  used  for  graphics.)  Next,  the 
stroke  operator  paints  the  path  with  the  current  color  and  line  width. 

The  PostScript  language  gives  complete  control  over  how  the  stroke  operator  converts  a  path  into 
a  painted  line  or  curve.  The  setlinewidth  operators  determine  the  width  of  the  stroked  line.  There 
are  several  operators  that  allow  other  characteristics  of  a  stroked  path  to  be  precisely  determined. 
Among  these  are: 

1 )  setlinecap  determines  the  appearance  of  line  segment  ends; 

2)  setlinejoin  determines  the  method  by  which  different  line  segments  are  joined; 

3)  setdash  determines  the  panera  for  dashed  lines. 

These  operators  are  described  below  in  detail: 

1.2.1.1  Setlinecap 

The  setlinecap  operator  takes  a  number  from  the  stack  and  uses  it  tu;  a  code  determining  how 
PostScript  will  end  stroke  line  segments.  For  example,  the  program  line 

1  setlinecap 

would  cause  PostScript  to  paint  all  line  segments  with  round  ends. 

There  are  three  values  for  the  line  cap  code: 

0.  Butt  caps  -  The  line  segment  has  square  ends  perpendicular  to  the  path.  This  is  the 
PostScript  default  line  cap. 

1 .  Round  caps  -  The  line  segment  ends  with  semicircular  caps  with  diameters  equal  to  the 
widths  of  the  line. 

2.  Projecting  square  caps  -  These  are  similar  to  butt  caps,  but  extend  one-half  of  a  line  width 
beyond  the  line  segment's  endpoinu  (These  three  styles  are  illustrated  in  Figure  1). 
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Figure  1.  Linecap  and  Linejoin  Capabilities 


L2.1.2  Setlinejoin 

When  two  connected  line  segments  are  stroked,  PostScript  needs  to  make  a  decision  about  what 
type  of  join  to  use  between  them.  The  setlinejoin  operator  tell  PostScript  how  to  join  connecting 
line  secerns.  This  operator  is  similar  to  setlinecap,  in  that  it  takes  a  code  from  the  top  of  the 
stack.  This  code  can  have  values  from  zero  to  two,  corresponding  to  the  following  types  of  line 
joins: 

0.  Mitered  join  -  The  edges  of  the  stroke  are  extended  until  they  meet.  This  is  the  default 
join.  This  join  is  affected  by  the  current  miter  limit  (see  below). 

1 .  Rounded  join  -  The  segments  arc  connected  by  a  circular  join  with  a  diameter  equal  to  the 
line  width. 

2.  Bevel  join  -  The  segments  are  finished  with  butt  end  caps  and  the  notch  at  the  larger 
angle  between  the  segments  is  filled  with  a  triangle. 

These  three  styles  are  illustrated  in  Figure  1. 

1.2. 1.3  Setmiterlimit 

Mitered  joins  can  present  a  problem.  If  two  line  segments  meet  at  an  extremely  small  angle,  the 
mitered  Join  can  produce  a  spike  that  extends  a  considerable  distance  beyond  the  intersection  of  the 
path  segments.  To  prevent  this,  the  join  switches  from  mitered  to  beveled  when  the  angle  between 
line  segments  becomes  too  acute.  Figure  2  illustrates  how  the  setmiterlimit  operators  is  used  to 
control  this  effect. 
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Figure  2.  Setmiterlimit  Capabilities 


1.2.1.4  Setdash 

The  current  path  is  normally  stroked  with  a  solid  line.  Other  methods  of  stroking  a  path  are 
possible,  however.  The  PostScript  graphics  state  includes  a  dash  array  and  a  dash  outset,  that 
together  describe  what  pattern  of  alternating  black  and  white  dashes  should  be  used  to  stroke  paths. 

This  pattern  is  set  by  the  setdash  operator,  which  takes  an  array  and  a  number  from  the  stack  and 
makes  them  the  current  dash  array  and  offset.  The  array  contains  a  set  of  numbers,  such  as 

[3  5  15] 

which  represent  the  lengths  of  alternating  black  and  white  segments  should  make  up  a  stroked  line. 

The  array  above  would  cause  all  paths  to  be  stroked  with  a  repeating  sequence  consisting  of  three 
units  of  black,  five  units  of  no  ink,  one  unit  black,  five  units  no  ink.  This  pattern  will  repeat  along 
the  entire  stroked  path.  This  is  illustrated  in  Figure  3. 


[351510  setdash 

Figure  3.  Setdash  Capabilities 

The  second  argument  passed  to  setdash  is  the  offset  within  the  dash  pattern  where  the  stroke 
operator  is  to  start  when  it  prints  a  line.  That  is,  if  we  were  to  set  the  dash  pattern  with  the  line 

[6  3]  3  setdash 

stroked  lines  would  begin  three  units  into  the  pattern,  or  half  way  through  the  first  long  dash. 
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1.2.1.5  Closepath 


A  final  necessary  capability  is  provided  by  the  closepath  operator.  This  operator  adds  a  line 
segment  to  the  current  path  connecting  the  current  point  to  the  last  point  addressed  by  a  moveto 
operator.  Figure  A  shows  an  example  of  a  box  containing  a  notch  in  one  comer  since  it  hasn't  been 
"closed."  After  the  closepath  operator  is  applied  (with  mitered  joins)  the  result  is  "better  box"  in 
Figure  4. 


A 

anitS 


Figure  4.  Closepath  Usage 


1.2.2  Symbols 

PostScript  provides  no  explicit  modular  symbol  capabilities.  Its  program  language-like  structure 
however,  allows  graphical  patterns  to  be  defined  once  and  positioned  at  various  points  to  provide 
the  necessary  capability.  This  topic  is  explored  further  in  Paragraph  3.8. 

1.2.3  Curves 

PostScript  provides  the  following  operations  to  draw  curve  line  segments; 

arc  -  appends  a  counterclockwise  arc  of  a  circle  to  the  current  path,  possibly  preceded  by  a  straight 
line  segment. 

aren  -  behaves  like  arc,  but  builds  its  arc  segment  in  a  clockwise  direction. 

arcto  -  appends  an  arc  of  a  circle  to  the  current  path,  preceded  by  a  straight  line  segment. 

curveto  -  adds  a  Bezier  cubic  section  to  the  current  path . 

moveto  -  starts  a  new  subpath  of  the  current  path,  sets  the  current  point  in  the  graphics  state  to  the 
user  coordinate  without  ading  any  line  segments  to  the  current  path. 

closepath  -  closes  the  current  subpath  by  appending  a  straight  line  segment  connecting  the  current 
point  to  the  subpaths's  staning  point. 

rlineto  •  appends  a  straight  line  segment  to  the  current  path  in  the  same  manner  as  lineto; 
however,  the  number  pair  is  interpreted  as  a  displacement  relative  to  the  current  point  rather  than  as 
an  absolute  coordinate. 
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rmoveto  -  starts  a  new  subpath  of  the  current  path  in  the  same  manner  as  moveto,  however,  the 
number  pair  is  interpreted  as  a  displacement  relative  to  the  current  point  rather  than  as  an  absolute 
coordinate. 

rcurveto  -  adds  a  Bezier  cubic  section  to  the  current  path  in  the  same  manner  as  curveto; 
however,  the  three  number  pairs  are  interpreted  as  displacements  relative  to  the  current  point  rather 
than  as  absolute  coordinates. 

stroke  •  paints  a  line  following  the  current  path  and  using  the  current  color. 

strokepath  -  replaces  the  current  path  with  one  enclosing  the  shape  that  would  result  if  the  stroke 
operator  were  applied  to  the  current  path. 

setflat  -  sets  the  flatness  in  the  current  graphics  state  to  num,  which  must  be  a  positive  number. 
Ratness  is  used  to  control  the  accuracy  with  which  curves  are  rendered  on  an  output  device 

clip  -  intersects  the  inside  of  the  current  clipping  path  with  the  inside  of  the  current  path  to  produce 
a  new  (smaller)  current  clipping  path. 

Additional  details  are  contained  in  Appendix  B  which  provides  a  complete  description  of  each 
operator  mentioned  above.  [  Registration  proposals  have  been  prepared  for  the  curve 
capability.  Some  others  have  equivalent  facilities  in  the  CGM.  Setflat,  closed 
figure  and  stroke  path  require  further  study  before  generalization  and 
incorporation  in  the  CGM.] 

1.2.4  Text 

Rather  than  draw  the  required  text  capabilities  from  PostScript— which  represents  only  one  of 
many  technologies  for  defining  and  rendering  text,  ISO  DP  9541  Font  and  Character  Information 
Interchange  is  used.  There  is  agreement  in  principle  amongst  the  various  standards  comminees  that 
the  capabilities  represented  in  this  draft  standard  should  be  adopted  by  computer  graphics 
standards. 

ISO  DP  9541  defines  font  referencing,  positioning,  and  presentation.  Minimal  and  complete 
capabilities  are  defined  in  each  of  these  areas  as  follows: 

1.2.4. 1.  Objectives  and  Functional  Definitions 

The  objective  of  the  Font  and  Character  Information  Interchange  Standard  is  to  define  a  common 
font  resource  architecture  which  can  be  used  in  a  variety  of  development  and  application 
environments,  for  the  purpose  of  supporting  text  (characters,  symbols,  ideograms)  generation, 
interchange,  and  presentation.  The  font  resources  which  are  developed  to  this  architecture  may  be 
used  by:  text  and  graphic  editor,  document  formatters,  utilities,  device  service  programs,  resource 
management  programs,  and  presentation  device  drivers.  Figure  E  provides  a  high  level  look  at  the 
environment  in  which  ISO  DP  9541  operates.  Figure  F  decomposes  Figure  E  to  provide  a  lower 
level  look  at  the  publishing  environment. 
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Figure  5.  ISO  Font  Architecture  -  Application  Environment 
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Figure  6.  A  Lower-level  Look  at  the  Font  Application  Environment 
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Consistency  of  font  resource  information  is  a  requirement  for  softcopy  display  of  documents  to  be 
typeset,  and  interchange  of  documents  between  systems. 

The  degree  of  consistency  can  be  significantly  improved  through  the  use  of  a  common  font 
resource  architecture. 

A  font  resource  is  defined  to  be  the  total  collection  of  information  required  to  characterize  and 
identify  a  font  to  compose  blocks  of  text  and  to  define  the  images  of  the  characters,  for  use  by  an 
electronic  data  processing  system.  A  font  resource  will  contain  ii^ormation  that: 

1)  identifies  and  describes  itself  to  permit  selection  by  users  and  applicadon  programs. 

2)  defines  the  character  attributes  required  by  a  document  formatting  process  to  posidon  the 
characters  on  a  presentadon  surface. 

3)  defines  each  character's  shape  for  generadon  of  the  character  images  on  the  presentation 
surface. 

Font  production  is  defined  to  be  the  process  of  designing  the  character  images,  converting  those 
images  into  a  distal  technolo^  format  (bit  image,  vector  drawing  orders,  outline  algorithm,  etc.), 
defining  the  various  height,  width,  and  escapement  values  for  each  individual  character,  assigning 
appropriate  descriptive  and  identifying  information  (to  the  characters  and  the  font  resource  in 
general),  and  creating  a  font  resource  that  contains  all  of  the  required  information  in  a  format  that 
can  be  used  by  a  text  processing  system. 

Text  processing  system  is  defined  to  be  the  total  collection  of  hardware  devices  and  software 
or  firmware  programs  required  to  generate,  mo<^,  display,  and/or  print  text  Those  components 
(devices  and  progmas)  may  be  contained  in  a  single  hardware  device  that  processes  only  text  or 
may  be  included  within  a  larger  document  processing  system  and/or  communication  network.  Text 
processing  may  be  the  primary  function  of  the  component  (text  editor)  or  it  may  be  only  an 
auxiliary  Action  of  the  component  (graphics  editor,  device  service  program,  resource  management 
program). 

Font  storage  and  access  is  defined  to  be  the  process  of  storing  the  font  file  information  on  the 
appropriate  media  for  use  within  a  text  processing  system,  and  the  process  of  accessing  that 
information  by  the  various  components  of  a  text  processing  system.  When  a  font  resource  is  first 
generated,  all  of  the  required  information  may  be  contained  in  a  single  font  resource  file,  but  that 
may  not  be  the  format  that  is  most  useful  within  a  text  processing  system 

Font  referencing  is  defined  to  be  the  process  of  identifying  or  characterizing  a  font.  The 
referencing  task  affects  editing,  formatting  and  presentation  because  it  is  necessary  for  the  user 
to  specify  the  desired  fonts  in  the  document,  for  the  formatter  to  identify  the  fonts  and  find  the 
required  character  positioning  information  from  the  appropriate  font  resource,  and  for  the 
presentation  process  to  identify  the  fonts  and  find  the  required  character  positioning  and  shape 
information  from  the  appropriate  font  resource.  Referencing  may  include  identification  of  a  specific 
font  resource,  or  simply  provide  sufficient  descriptive  information  about  the  desired  font  that  an 
alternative  font  resource  can  be  found  if  the  specified  one  is  not  available  to  the  system  which  will 
format  or  present  the  document. 

Character  positioning  is  defined  to  be  the  process  of  determining  where  a  given  character  is  to 
appear  on  the  presentation  surface.  This  function  is  performed  by  the  document  formatting  process, 
which  is  a  generic  name  for  any  process  that  determines  the  text,  graphic,  or  image  content  and 
format  of  a  document,  including  pages  and  line  breaks  and  how  text  should  flow  around  graphics 
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or  image  objects  that  also  appear  in  the  document.  The  document  formatting  process  makes  use  of 
font  resource  information  along  with  user,  system,  and  document  content  information.  Thus,  font 
resources  provide  only  a  portion  of  the  information  required  for  character  positioning.  Characters 
may  be  positioned  absolutely  or  relatively.  That  is,  the  formatting  process  may  specify  the  precise 
location  where  each  individual  character  is  to  be  positioned  or  the  formatting  process  may  specify 
the  content  and  beginning  of  a  string  of  characKrs.  In  either  case,  the  process  must  know  the  image 
and  escapement  extents  for  each  individual  character,  and  other  character  attributes  dealing  with 
coendinate  system,  reference  point,  rotation,  kerning,  ligatures,  etc. 

Image  presentation  is  defined  to  be  the  process  of  forming  the  character  image  on  the 
presentation  surface.  This  process  is  acmally  performed  by  a  hardware  device  (display  or  printer), 
but  may  be  supponed  by  a  series  of  software  and/or  hardware  processes  which  translate  the 
character  image  information  from  its  font  resource  format  to  the  format  or  control  codes  required 
by  the  presentation  device.  Font  resources,  defined  according  to  this  standard,  may  support  a 
variety  of  shape  defiiution  techniques,  some  public  and  some  private.  Some  font  designs  are 
privately  owned  and  the  key  to  translation  of  the  character  shape  information  is  only  available 
through  license  agreements.  Other  font  designs  are  in  the  public  domain  and  anyone  may  have 
access  to  the  character  shape  information.  In  addition,  other  practical  considerations  may  suggest 
the  use  of  other  image  technologies. 

1.2.4.2  Font  Referencing 

Minimal  Referencing 

The  minimal  subset  of  font  referencing  supports  simple  identification  of  the  font  resource  design 
and  character  content,  but  does  not  supp<m  description  of  the  font  resource  to  a  level  of  detail 
required  for  suppon  of  document  rendering  (fidelity  level)  specification.  The  subset  only  includes 

font  name. 

Complete  Referencing 

The  complete  subset  level  of  the  font  referencing  supports  description  of  the  font  resource  to  a  level 
that  permits  selection  or  approximation  of  a  font  resource  based  on  the  description  provided.  The 
selected  font  must  be  described  to  a  level  of  detail  that  accurately  identifies  the  attributes  of  the  font 
resource  that  was  chosen  for  document  formatting.  If  it  becomes  necessary  for  the  presentation 
service  to  substimte  another  font  resource,  it  must  find  one  that  most  closely  corresponds  to  both 
the  user  and  formatter  specified  fonts. 

The  subset  includes  the  following  attributes  (in  addition  to  those  defined  for  the  minimal  subset): 

Control  attribuus 
body  size  units 

Control  attributes 
charaaer  collection 

Format  attributes 
font  size 
minimum  size 
maximum  size 

Layout  attributes 
maximum  height 
X  height 
cap  height 
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ascender  height 
descender  depth 
minimum  escapement 
average  escapement 
maximum  escapement 
weighted  average  escapement 
lower  case  escapement 
upper  case  escapement 
di^t  escapement  type 
writing  tnode 

Appearance  attributes 
posture 
structure 
mood 
function 

character  categcxy 
font  category 
typ^acename 
design  classification 
escapement  class 

hairline  weight 
relative  wei^t 
absolute  weight 
relative  width 
absolute  width 
relative  hei^t 
absolute  height 

1.2.4.3  Character  Positioning 
Minimal  Positioning 

The  minimal  subset  of  character  positioning  suppons  charaaer  increment  fonts,  but  docs  not 
suppon  proportionally  spaced  fonts  where  each  character  has  a  defined  escapement  value. 

This  subset  includes  the  following  attributes: 

Control  attributes 
font  name 
escapement  class 
bodysize  units 

Positioning  attributes 
average  escapement 
font  size 

Complete  Positioning 

Given  the  document  formatting  requirements  and  text  content,  the  escapement  required  for  each 
character  must  be  determined.  The  formatting  process  may  designate  that  a  character  may  be 
positioned  anywhere  on  the  presentation  surface.  To  prevent  unwanted  character  overiap,  excessive 
gap  between  characters,  or  characters  running  off  the  edge  of  the  presentation  space,  the  values  of 
each  character's  recommended  escapement  must  be  known. 
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This  subset  includes  the  following  attributes  (in  addition  to  those  defined  for  the  minimal  subset): 

Control  attributes 

minimum  space  amplification 
maximum  space  amplification 
pairwise  escapement  adjustment 

These  attributes  are  repeated  for  each  character  and  for  each  writing  mode  supported  by  the  font 
resource. 

Positioning  attributes 
char^irter  name 
writing  mode 
position  point 
escapement  point 
extents  (4  vdues) 
sectored  space  adjustment 
amplification 
correction 

white  space  adjustment 
op’s 

Formatting  programs  may  use  the  positioning  information  to  determine  each  character's  position  on 
a  presentation  surface,  with  each  character  being  presented  at  its  designated  point.  Or,  the 
formulating  program  may  designate  the  starting  point  (and  the  text  character  string,  with  each 
character  provid^g  information  needed  for  the  next  character's  presentation  position). 

1.2.4.4  Image  Presentation 

The  information  contained  in  these  subsets  may  be  stored  and  used  separately  from  the  information 
contained  in  the  function  sets  defrned  for  referencing  and  positioning.  A  font  resource  may  not  be 
identified  as  supporting  one  of  these  subsets  unless  it  contains  all  of  the  attributes  defined  for  chat 
subset  That  is,  if  a  resource  contains  all  font  attributes  exc^t  one  from  the  minimal  subset,  then 
the  resource  cannot  be  identified  as  supporting  either  the  minimal  or  the  complete  subset 

.Minimal  Presentation 

The  minimal  subset  level  of  character  presentation  supports  only  the  bitmap  format  of  character 
image  definition.  Alternate  formats  will  not  be  recogniz^ 

This  subset  includes  the  following  attributes: 

Control  attributes 
font  name 
bodysize  units 

Presentation  attributes  (per  charaaer  and  rotation) 
character  name 
charaaer  shape  information 

The  attributes  for  this  format  will  be  defined. 

This  is  the  basic  format  required  for  definition  of  character  shapes  for  the  registration  of  characters 
for  Part  3  of  the  ISO  DP  9M1  standard. 
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Complete  Presentation 

Given  the  positioning  point  for  a  character,  the  shape  of  the  character  must  be  presented  on  the 
presentation  surface  using  the  device  technology  applicable  to  that  device.  All  character  shape 
information  is  defined  relative  to  an  origin,  which  has  a  defined  x-y  offset  and  rotation  from  the 
escapement  box  origin  (current  positioning  point).  Non-ISO  character  image  technologies  do  not 
need  to  be  supponed  by  this  subset  level. 

Control  attributes 
image  technology 

Presentadon  attributes  (per  character  and  rotadon) 
charaaer-shape  informadon  for. 
straight  line  outline 
circular  outline 
conic  outline 
Bezier  outline 
composite 

The  shape  informadon  may  be  defined  s^arately  for  each  device  technology,  but  there  should  be 
one  set  of  device  independent  posidoning  informadon  for  each  resource  ID.  Thus,  the  shape 
informadon  may  be  related  for  several  different  technologies  in  any  one  font  resource,  or  the 
shape  and  posidoning  iifformadon  may  be  contained  in  separate  files  with  cross  reference  pointers. 

1.2.5  Images 

PostScript  includes  a  very  minimal  set  of  capabilides  for  handling  images  (raster  bitmaps).  The 
operators  provided  are : 

image — rcnden  a  sampled  image  onto  the  current  page.  The  sampled  image  is  a  rectangle  array  of 
width  X  height  sample  values,  each  of  which  consists  of  bits  sample  bits  of  data  (1, 2, 4,  or  8). 

imagemask — similar  to  the  image  operator,  however,  it  tracks  the  source  image  as  a  mask  of  1 
bit  sample  that  is  used  to  control  where  to  apply  paint  (with  the  current  color)  and  where  not  to.  It  is 
most  useful  for  prindng  characters  as  bitmaps.  Such  bitmaps  represent  masks  through  which  a 
color  is  to  be  transformed. 

The  image  capabilities  are  too  limited  to  meet  CALS  requirements  (or  those  of  the  publishing 
industry  in  general).  This  topic  requires  further  study.  [The  CGM  can  be  extended  to 
incorporate  a  very  general  set  of  facilities  compatible  with  the  raster  portions  of 
Group  4  facsimile.] 

1.2.6  Definition  and  Instantiation  of  Objects 

One  capability  that  is  missing  in  the  CGM  is  the  ability  to  define  an  arbitrary  picture  component 
(e.g.  a  symbol  or  non-primidve  object)  which  can  be  instanced  (repeated)  multiple  times  with  a 
single  picture  or  over  shared  amongst  different  pictures  in  a  document. 

As  will  be  further  discussed,  this  capability  is  needed  for  both  publishing  and  engineering  drawing 
applications. 

The  capabilities  of  both  PostScript  (based  on  a  programming  language  approach)  and  Interpress 
(based  upon  defining  extended  operators)  are  described  below.  Appendix  B  contains  detailed 
descriptions  of  the  corresponding  PostScript  and  Interpress  features. 
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1.2.6.1  PostScript  Procedures 

A  PostScript  procedure  is  a  set  of  operations  grouped  together  with  a  common  name.  This  set  of 
operations  is  stored  with  its  key  in  a  dictionary.  When  the  key  appears  in  a  program,  the  associated 
set  of  operations  is  carried  out 

Procedures  are  defined  in  exactly  the  same  way  as  variables.  The  program  must  place  the  procedure 
name  (preceded  by  a  slash)  on  the  stack,  followed  by  the  set  of  operations  that  make  up  the 
procedure.  Then,  the  def  operator  is  used  to  store  the  operations  and  name  in  the  current 
dictionary. 

1.2.6.2  Interpress  Symbols 

The  concepts  of  symbol  and  instance  are  provided  in  Interpress  by  composed  operators  and 
transformations.  A  graphical  symbol  can  be  defined  as  a  composed  operator.  When  an  instance,  or 
copy,  of  the  symbol  is  to  be  printed,  the  current  transformations  will  be  applied  to  all  coordinates  as 
the  symbol  ct^s  imager  opmtors.  The  properties  of  the  current  transformation  will  thus,  determine 
the  position,  size,  and  rotation  of  the  instance  on  the  printed  page. 

The  principal  use  of  symbols  and  instances  in  Inttrpress  is  for  printing  charaaers.  Each  charaaer  is 
defined  by  a  compost  operator,  called  a  character  operator.  These  operators  are  invoked  usually 
by  SHOW,  with  a  current  transformation  that  achieves  the  proper  size,  orientation  and  position  of 
the  character. 

Instancing  can  also  be  used  for  other  purposes.  Graphical  objects  that  are  repeated  often  on  a  page 
or  throu^out  a  document  may  be  tracked  as  instances.  A  symbol  is  defined  as  a  composed 
operator  and  called  with  an  appropriate  current  transfomoation  in  order  to  generate  each  instance. 
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2.0  Technical  Drawings  and  Product  Data 
2.1  Introduction 

It  is  recognized  that  some  extensions  to  computer  graphics  standards  are  necessary  to  properly 
suppon  the  creation  of  drawings  and  views  of  product  model  data.  The  following  extract  from  the 
Final  NBS  Report  for  CALS  -  FY86  sunmiarize  a  contractor's  findings; 

The  addition  of  several  facilities  to  the  graphics  standards  would  ^atly  improve  the  ability  of 
these  standards  to  efficiently  represent  the  drawings  and  views  implicit  in  IGES  and  PDES 
files.  These  additions  are  describe  in  the  following  paragraphs. 

Support  for  full  conics  including  hyperbolas  and  parabolas 

Suppon  for  splines,  including  at  least  one  of  the  parametric  spline  and  rational  B-spline 
representations. 

Support  for  surface  definitions,  including  surfaces  of  revolution  and  cylinders. 

Support  for  a  ROUNDED  RECTANGLE  output  primitive. 

Support  for  many  new  line  types,  including  some  or  all  of  the  1 1  forms  of  "arrows  ” 
defined  in  IGES  through  registration  and  subsequent  standardization. 

Support  for  the  CENTERLINE  symbol  as  new  standardized  marker  type. 

Addition  of  facilities  to  more  directly  control  and  specify  such  features  of  text  strings  as 
subscripts,  superscripts,  and  fractions.  At  present,  these  features  can  be  generated  only 
by  using  the  more  primitive  APPEND  TEXT  and  by  changing  associated  text  attributes 
like  CHARACTER  HEIGHT,  CHARACTER  SPACING,  and  TEXT  ALIGNMENT. 

In  IGES/PDES  the  slant  of  the  text  is  independently  specified  from  the  type  face  fe.g., 
Helvetica  Italics  Bold).  The  Computer  Graphics  Interface  (CGI)  standard  allows,  via  the 
Character  Orientation  element,  text  characters  to  be  skewed  ("slanted").  This  feature  is  not 
directly  available  in  the  Graphical  Kernel  Sytem  (GKS)  standard  and  the  Programmers 
Hierarchical  Interface  Graphics  System  (PHIGS)  standard;  it  can  occur  only  as  a  result  of 
the  segment  or  structure  transformations. 

In  PDES,  continuous  text  alignment  is  used  to  align  multiple  text  strings.  This  feature  is 
also  available  in  CGI/CGM.  It  should  be  added  to  GKS,  GKS-3D  (GKS  in  three 
dimensions)  and  PHIGS. 

The  six  predefined  IGES  SECTION  entity  patterns  not  corresponding  to  standardized 
CGI/CGM  panems  should  be  registered. 

Support  for  user-defined  line  types. 

S  upport  for  multiple  color  tables. 

NBS/ICST  generally  supports  these  conclusions,  although  recommendations  made  in  this  report 
are  more  comprehensive  and  somewhat  different  than  those  above  for  extensions  in  several  areas. 
Further,  this  work  is  limited  to  extensions  to  the  CGM  as  dictated  by  the  actual  requirements  from 
standards  for  product  data  description  and  drawings  themselves,  rather  than  tiing  limited  to 
investigation  of  the  IGES  standard  (which  does  not  describe  engineering  drawings,  per  se.  but 
rather  the  transfer  of  the  complete  information  necessary  to  describe  the  representation  of  a 
product.) 
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The  methodology  used  to  define  the  capabilities  required  to  define  images  of  engineering  drawings 
was  the  following: 

1.  Review  requirements  from  the  standards  for  the  production  of  engineering  drawings  listed  in 
Section  3.0  of  the  Background  section  above;  then  extract  the  required  representational  capabilities 
needed  in  the  CGM. 

2.  Review  the  IGES  standard  to  extract  entities  for  which  the  CGM  must  be  able  to  describe 
images;  then  extract  the  required  representational  capabilities  needed  in  the  CGM. 

3.  Consider  the  CALS  system  level  requirements  in  areas  such  as  use  of  symbol  libraries.  Since  no 
such  requirements  exist  in  explicit  form  and  there  is  no  well-defined  CALS  reference  model,  the 
capabilities  of  commercially  available  products  were  used  to  derive  requirements. 

2.2  IGES  Entities 

IGES  Version  3.0  contains  the  following  types  of  entities.  Each  of  these  entities  and  suggestions 
on  how  it  might  be  rendered  by  systems  implementing  graphics  standards  are  described  in 
Appendix  C.  TTus  material  was  extracted  from  ^e  Final  NBS  Report  for  CALS  -  FY86.  The  CGM 
must  be  capable  of  describing  images  (graphical  representations)  of  these  entities: 

CIRCULAR  ARC 
COMPOSITE  CURVE 

CONIC  ARC  -  registration  proposal  prepared 

COPIOUS  DATA 

PLANE 

LINE 

PARAMETRIC  SPLINE  -  registration  proposal  prepared 

PARAMETRIC  SPLINE  SURFACE 

POINT 

RULED  SURFACE 
SURFACE  OF  REVOLUTION 
TABULATED  CYLINDER 
TRANSFORMATION  MATRIX 
FLASH  ENTITY 

RATIONAL  B-SPLINE  -  registration  proposal  prepared 

RATIONAL  B-SPLINE  SURFACE 

OFFSET  CURVE 

CONNECT  POINT 

NODE 

FINITE  ELEMENT 

NODAL  DISPLACEMENT  AND  ROTATION 

OFFSET  SURFACE 

CURVE  ON  PARAMETRIC  SURFACE 

TRIMMED  (PARAMETRIC)  SURFACE 

ANGULAR  DIMENSION 

CENTERLINE 

DIAMETER 

FLAG  NOTE 

GENERAL  LABEL 

GENERAL  NOTE 

LEADER 

LINEAR  DIMENSION 
POINT  DIMENSION 
RADIUS  DIMENSION 
SECTION 
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GENERAL  SYMBOL 
SECTIONED  AREA 
WITNESS  LINE 
ASSOCIATTVOTY  DEFINITION 
ASSOCIATIVITY  INSTANCE 
DRAWING 

LINE  POINT  DEFINITION 
MACRO  CAPABILITY 
PROPERTY 

SUBFIGURE  DEFINITION 
TEXT  FONT  DEFINITION 
VIEW  ENTITY 

EXTERNAL  REFERENCE  ENTITY 
NODAL  LOAD/CONSTRAINT  ENTITY 
COLOR  DEFINITION  ENTITY 
TEXT  DISPLAY  ENTITY 

2.3  Required  Capabilites 

2.3.1  Lines 

The  following  material  is  drawn  from  ANSI  Y14.2M-1979  (Line  Conventions  and  Lettering)  and 
explains  how  "lines"  are  used  in  produa  definition  drawings: 

Line  widths  •  Two  widths  of  lines  are  recommended  for  use  on  manually  prepared  drawings. 
(See  Figure  7.)  One  width  of  line  is  acceptable  on  drawings  prepared  by  automated  methods.  The 
ratio  of  line  thickness  should  be  approximately  two-to-one.  The  thin-line  width  should  be 
approximately  0.35  mm  or  0.016  inch  and  the  thick-line  width  approximately  0.7  mm  or  0.032 
inch.  The  actual  width  of  each  line  should  be  governed  by  the  sizes  and  styles  of  drawing,  and  the 
smallest  size  to  which  it  is  to  be  reduced.  Ail  lines  of  the  same  type  should  be  uniform  throughout 
the  drawing.  Spacing  between  parallel  lines  should  be  such  that  there  is  no  fill-in  when  reproduced 
by  available  photographic  methods.  Note:  spacing  of  no  less  than  1.5  mm  (0.06  inch)  normally 
meets  reproduction  requirements. 

Line  quality  -  All  lines  should  be  clean  cut,  opaque,  uniform,  and  properly  spaced  for  legible 
reproduction  by  all  commonly  used  methods,  including  microfilming  in  accordance  with  industry 
and  government  requirements.  When  manually  produced,  there  should  be  a  distinct  contrast 
between  the  two  widths  of  lines.  Contrast  must  be  obtained  only  by  variance  in  the  relative  widths 
of  the  lines.  In  no  case  should  contrast  be  achieved  by  a  difference  in  density,  opaqueness  or  color. 

Visible  lines  -  The  visible  lines.  Figure  7  and  8,  should  be  used  for  representing  visible  edges  or 
contours  of  objects.  Visible  lines  should  be  drawn  so  that  the  views  they  outline  clearly  stand  out 
on  the  drawing  with  a  definite  contrast  between  these  lines  and  secondary  lines. 

Hidden  lines  -  Hidden  lines.  Figures  7  and  8,  consist  of  shon  evenly  spaced  thin  dashes  and  are 
used  to  show  the  hidden  features  of  the  object.  The  lengths  of  the  dashes  may  vary  slightly  in 
relation  to  the  size  of  the  drawing.  Hidden  lines  should  always  begin  and  end  with  a  dash  in  contact 
with  the  visible  or  hidden  line  from  which  they  stan  or  end,  except  when  such  a  dash  would  form  a 
continuation  of  a  visible  line.  Dashes  should  join  at  comers,  and  arcs  should  stan  with  dashes  at 
tangent  points.  Hidden  Lines  should  be  omitted  when  their  use  is  not  required  for  the  clarity  of  the 
drawing.  Although  features  located  transparent  materials  may  be  visible,  they  should  be  treated  as 
concealed  features  and  shown  with  hidden  lines. 

Section  lines  -  Section  lines.  Figures  7  and  8,  are  used  to  indicate  the  cut  surfaces  of  an  object  in 
a  section  view. 
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Center  lines  -  Center  lines.  Figures  7  and  8  consist  of  alternating  long  and  shon  dashes.  They 
are  used  to  represent  axes  of  symmetrical  parts  and  features,  bolt  circles,  and  paths  of  motion.  The 
long  dashes  of  the  center  lines  may  vary  in  lengths,  depending  upon  the  size  of  the  drawing.  Center 
lines  should  start  and  end  with  long  dashes.  They  should  not  intersect  at  the  spaces  between  dashes 
or  by  crossing  the  long  or  short  dashes.  Center  lines  should  extend  uniformly  and  distinctly  a  shon 
distance  beyond  the  object  or  feature  of  the  drawing  unless  a  longer  extension  is  required  for 
dimensioning  or  for  some  other  purpose.  They  should  not  terminate  at  other  lines  of  the  drawing 
nor  should  they  extend  through  the  space  between  views.  Very  short  center  lines  may  be  unbroken 
if  no  confusion  results  with  other  lines. 

Symmetry  lines  -  This  is  a  center  lines  used  as  an  axis  of  symmetry  for  a  partial  view.  The  line 
of  symmetry  is  identiHed  by  two  thick  short  parallel  lines  c^wn  at  right  angles  to  it.  They  are 
used  in  representing  partially  drawn  views  and  partial  sections  of  symmetrical  parts.  Symmetrical 
view  visible  and  hi^en  lines  may  extend  past  the  symmetry  line  if  clarity  would  be  improved. 

Dimension  lines  -  Dimension  lines.  Figure  7  and  8  are  used  to  indicate  the  extent  and  direction 
of  dimensions  and  are  terminated  by  neatly-made  uniform  arrowheads.  The  length  of  die  arrowhead 
should  be  equal  to  the  height  of  the  dimension  numerals  if  possible.  If  inadequate  space  is 
available,  the  arrowhead  may  be  shown  outside  the  dimension  limit. 

Extension  lines  -  Extension  (wimess)  lines.  Figures  7  and  8,  are  used  to  indicate  the  point  or 
line  on  the  drawing  to  which  the  dimension  applies.  A  short  gap  is  left  where  the  extension  line 
would  join  the  object,  so  as  not  to  confuse  extension  lines  with  the  lines  of  the  object 

Extension  lines  are  also  used  to  indicate  the  extension  of  a  surface  to  a  theoretical  intersection. 
When  a  point  is  located  by  extension  lines,  the  extension  lines  should  pass  through  the  point 

Leaders  •  Leaders,  Figures  7  and  8,  are  used  to  direct  notes,  dimensions,  symbols,  item 
numbers,  or  pan  numbers  to  features  on  the  drawing.  A  leader  should  generally  be  a  single  straight 
inclined  line  (not  vertical  or  horizontal),  except  for  a  shon  horizontal  pmtion  extending  to  the  center 
of  the  height  of  the  first  or  last  letter  or  digit  of  the  note.  This  horizontal  portion  is  optional  and  if 
used  it  should  not  underline  the  note. 

The  leaders  should  terminate  as  follows: 

a)  Without  symbol,  if  they  end  on  a  dimension  line  . 

b)  With  a  dot  1 .5  mm  or  0.06  inch  niinimum  diameter,  if  they  end  within  outlines  of  an  object . 

c)  With  an  arrowhead,  if  they  end  on  the  outside  of  an  object 

d)  With  or  without  a  dot  or  arrowhead  on  drawings  prepared  by  computer  automated  techniques. 

Leaders  should  not  be  curved  in  any  way  and  should  not  cross  each  other  unless  unavoidable.  Two 
or  more  leaders  to  adjacent  areas  on  the  drawing  should  be  drawn  parallel. 

Cutting-plane  lines  -  Cutting-plane  and  viewing-plane  lines.  Figures  7  and  8,  are  used  to 
indicate  the  location  of  cutting  planes  for  sectional  views  and  the  viewing  position  for  removed 
partial  views.  Two  forms  of  cutting-plane  and  viewing-plane  lines  are  approved  for  general  use. 

Break  Lines  -  Two  forms  of  break  lines  are  approved  for  general  use  as  follows: 

a)  A  freehand  thick  line.  (See  Figure  7,  line  10.) 

b)  Long  ruled  thin  dashes  joined  by  zigzags.  (See  Figure  7,  line  1 1.) 
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Phantom  lines  -  Phantom  lines  (Figure  7,  line  12)  consist  of  long,  thin  dashes  separated  by  pairs 
of  short,  thin  dashes.  The  long  dashes  may  va^  in  length,  depending  on  the  size  of  the  drawing. 
Phantom  lines  are  used  to  indicate  alternate  ^sidons  of  moving  parts  (Figure  8);  adjacent  positions 
of  related  parts;  and  repeated  detail.  These  lines  are  also  used  for  features  such  as  bosses  and  lugs 
(later  moved);  for  delineating  machining  stock  and  blanking  developments;  for  piece  parts  in  jigs 
and  fixtures;  and  for  bend  lines  on  drawings  or  formed  metal  parts.  Phantom  lines  should  stan  and 
end  with  long  dashes  which  may  vary  in  length,  depending  on  the  size  of  die  drawing. 

Stitch  lines  -  Sdtch  lines  (Figure  7,  lines  13  and  14)  consist  of  short,  thin  dashes  and  spaces  of 
equal  lengths.  The  dots  are  approximately  0.016  (0.35  mm)  in  diameter  and  0.12  inch  (3  mm) 
apart..  Sdtch  lines  are  used  for  indicating  a  sewing  or  stitching  process. 

Chain  lines  -  The  chain  line  (Figure  7,  line  15)  consist  of  thick,  alternating  long  and  shon 
dashes.  This  line  is  used  to  indicate  that  a  surface  or  surface  zone  is  to  receive  additional 
manufacturing  treatment  within  limits  specified  on  the  drawing.  (See  Figure  8.) 

Arrowheads  -  Arrowheads  may  be  prepared  manually  or  mechanically.  The  length  and  width 
should  have  a  ratio  of  approximately  3:1.  The  width  of  the  arrowhead  should  be  proportionate  to 
the  thickness  of  the  lines  used.  Consistency  of  the  style  of  an  arrowhead  should  contained 
throughout  the  drawing.  See  Figure  9  for  acceptable  arrowhead  styles. 


Figure  9,  Arrowhead  Styles 

In  addition  to  the  generic  line  types  defined  in  ANSI  Y14.2M,  ANSI  and  DoD  standards  in  specific 
areas  require  the  use  of  additional  types  of  lines.  Insufficient  time  is  available  at  present  to  fully 
investigate  these  and  categorize  them.  To  illustrate  the  general  nature  of  the  need  for  such  lines 
types.  Appendix  A  contains  extracts  from  two  Military  Standards  define  other  linestyles  and  specify 
their  meanings. 

In  summary,  many  additional  linestyles  are  required  to  suppon  engineering  drawings.  There  are 
additional  requirements  on  how  patterns  start  and  end  within  line  segments  beyond  those  that 
computer  graphics  standards  alone  can  satisfy.  Some  of  these  restrictions  may  need  to  be  stated  in 
the  CALS  application  profile  since  they  go  beyond  what  can  be  specified  through  the  registration 
process  alone.  For  example,  there  are  special  rendition  requirements  for  hidden  lines  that  cannot  be 
satisfied  by  a  polyline  primitive  with  the  appropriate  linestyle  alone.  This  happens  because  the 
conformance  requirements  for  computer  graphics  standards  do  not  specify  how  linestyle  patterns 
must  be  continued  from  segment  to  segment  within  a  polyline,  nor  do  they  specify  how  such  a  line 
must  end.  NBS/ICST  will  write  registration  proposals  for  such  items  to  include  the  additional 
conformance  requirements,  however,  they  may  be  rejected  by  the  standards  committees. 
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[  Note:  A  linetype  registration  proposal  has  been  prepared  for  each  of  the  above 
linestypes«  with  the  following  exceptions: 

•  visible  lines  can  be  done  with  linetype  solid; 

-  symmetry  lines  cannot  be  done  with  a  single  graphical  line  of  any  type;  a  symbol 

facility  could  be  used,  or  a  set  of  individual  line  elements; 

-  single  and  double  arrow  linetype  can  be  used  for  leaders  and  dimension  lines; 

•  cutting  plane  lines  must  be  done  as  a  set  of  individual  lines  since  they  can't  be 

represented  as  a  single  linetype. 

Some  restrictions,  such  as  allowable  widths  of  lines  and  styles  of  text  in 
engineering  drawings,  will  need  to  be  stated  in  the  application  profile  for  CALS.] 

2.3.2  Symbols 

The  general  intent  of  this  section  is  to  illustrate  that  the  requirements  for  symbols  in  engineering 
drawings  cannot  be  met  by  the  polymarker  primitives  of  the  graphics  standards. 

International  Standard  ISO  3461  defines  the  general  characteristics  of  symbols  used  in  engineering 
drawings.  This  International  Standard  applies  to  graphics  symbols  which  may  be; 

a)  placed  on  equipment  at  parts  of  equipment  of  any  kind  in  order  to  instruct  the  persons 
handling  the  ^uipment  as  to  its  use  arid  operation; 

b)  placed  on  sites  and  ways  where  people  may  assemble  or  move,  giving  them  instructions, 
such  as  prohibitions,  wanungs,  rules  or  limits,  regarding  their  behavior 

c)  used  in  pictorial  reproductions,  such  as  plans,  drawings,  layouts,  guidelines  and  similar 
documents. 

Definitions 

For  the  purposes  of  ISO  3461,  the  following  definition  applies: 

Graphic  symbol:  A  visually  perceptible  figure  produced  by  means  of  writing,  drawing,  printing 
or  other  manufacturing  techniques.  It  is  used  to  transmit  a  message  and  represents  in  an 
understandable  manner,  independently  of  any  language,  an  object,  concept  or  state. 

Graphics  symbols  stand  for  objects,  concepts  or  states.  (What  a  symbol  stands  for  is  usually 
known  as  the  "referenL")  This  includes  abstract  references  such  as  conditions,  relationships,  facts 
or  actions. 

Functions 

As  a  rule,  graphic  symbols  are  used  to; 

a)  identify  (for  example  to  describe  a  piece  of  equipment  or  an  abstract  concept); 

b)  qualify  (for  example  to  describe  a  variation  or  a  secondary  function); 

c)  instruct  (for  example  to  describe  an  operation  or  method  of  use): 

d)  command! that  something  must  or  must  not  be  done); 

e)  warn  (for  example  of  danger); 

f)  indicate  (for  example  direction,  quantity). 
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Graphic  Form 


For  each  graphic  symbol  that  is  required  an  original  design  is  prepared.  An  original  design  is  a 
symbol  design  drawn  and  presented  in  the  manner  described  below,  i.e..  drawn  out  on  the  basic 
pattern  with  due  regard  to  the  principles  defined  below.  The  basic  pattern  described  below 
constitutes  a  frame  in  which  the  origin^  design  may  be  inscribed.  The  lines  indicated  in  the  basic 
pattern  (circles,  hexagons,  octagons,  squares,  etc.)  are  intended  as  an  aid  to  the  designer  in 
drawing  up  the  original  designs.  The  form  of  the  graphics  symbols  should  be  suitable  for 
economical  reproduction  by  means  of  commonly  applied  techniques,  such  as  etching,  engraving, 
printing,  and  photographic  means. 

Basic  Pattern 

The  basic  pattern  (Figure  10)  comprises: 

1)  a  basic  square  of  side  50  mm;  this  measure  is  equal  to  the  nominal  measure,  a ,  of  the  original 

2)  a  basic  circle  of  36  mm  diameter  having  approximately  the  same  area  as  the  basic  square; 

3)  a  second  circle  of  SO  mm  diameter,  being  the  inscribed  circle  of  the  basic  square  (1); 

4)  a  second  square  of  side  40  mm,  which  touches  the  basic  circle  (2)  with  its  comer, 

5)  a  rectangle  of  approximately  the  same  area  as  the  basic  square  (1),  with  the  long  side  (62.5 
mm)  horizontal  and  symmetrical  with  the  t^ic  square; 

6)  a  second  rectangle  having  approximately  the  same  area  as  the  basic  square  (1),  with  its  long 
side  (62.5  mm)  vertical  and  symmetrical  with  the  basic  square; 

70  a  third  square  formed  by  the  lines  passing  through  the  points  of  intersection  of  the  basic  square 
(1)  and  the  basic  circle  (2);  the  sides  of  tMs  square  are  oriented  at  45  degm  to  the  basic  square 
and  the  comers  of  this  square  define  the  limits  of  the  horizontal  and  vertical  dimensions  of  the 
basic  pattern; 

8)  an  irregular  octagon  formed  by  lines  inclined  at  30  degrees  to  the  sides  of  the  square  (7); 

The  basic  pattern  is  laid  upon  a  75  mm  x  75  mm  square  subdivided  by  a  12.5  mm  square  grid 
which  also  coincides  with  the  basic  square  (1). 

The  original  design  of  a  graphics  symbol  should  be  fitted  into  the  basic  pattern  according  to  the 
following  principles: 

1)  for  a  symbol  consisting  of  a  single  geometrical  form,  such  as  a  circle  or  a  rectangle,  the 
corresponding  geometrical  forms  of  the  basic  pattern  should  be  used,  in  which  case  the  lines  of 
the  basic  pattern  should  be  the  center  lines  of  the  .  1  inch  thick  lines  of  the  symbol  being 
designed; 

2)  to  achieve  the  impression  of  uniform  perceived  size  among  symbols,  anention  should  be  given 
in  the  equalization  of  surface  areas;  for  example,  a  circle  without  external  pans  should  be 
drawn  upon  the  basic  circle  (2)  (see  Figure  1 1,  pan  C)  whereas  a  circle  with  external  pans 
should  be  drawn  upon  the  smallest  circle  (3)  (see  Figure  1 1,  pan  D). 

Figure  1 1  gives  several  examples  of  symbols  created  according  to  this  standard. 
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<  8 
Figure  H.  Examples  of  Symbols 
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Orientation  of  the  Symbols 

The  majority  of  graphic  symbols  preserve  their  meaning  in  any  position.  However,  when  the 
meaning  of  a  graphic  syTnbol  does  depend  on  its  orientation  of  position,  this  shall  be  explicitly 
stated.  Figure  12  illustrates  a  graphics  symbol  not  dependent  on  its  position  (a  television  receiver), 
and  a  graphic  symbol  dependent  on  its  position  (a  "bar  ")- 

The  statement  concerning  the  posidon  dependency  could  read  as  follows: 

"The  meaning  of  the  graphic  symbol  depends  on  its  posidon.  Care  shall  be  taken  that  it  is  not 
reproduced  on  rotating  controls." 


Figure  12.  Symbol  Orientation 
Use  of  Symbols  in  Engineering  Drawings 

Figure  13  illustrates  the  typical  use  of  symbols  in  engineering  drawings.  A  large  number  of  simple 
symbols  are  used  repetitively  in  different  locations  to  construct  the  drawing.  Such  drawings  sho^d 
not  be  transferred  by  building  each  symbol  from  pt^tives  available  in  the  CGM,  nor  is  it  feasible 
to  make  each  requital  symbol  a  Generalized  Drawing  Primitive  or  marker  symbol.  It  is  absolutely 
essential  that  any  technique  used  to  transfer  such  draAvings  allow: 

1 )  a  symbol  to  be  defined  once  in  a  picture  and  then  instanced  repetitively; 

2)  externally  defined  symbols  from  standard  libraries  to  be  included  by  reference. 

This  must  be  done  for  these  reasons: 

1 )  to  reduce  the  required  communication  bandwidth; 

2)  to  reduce  the  storage  required  for  the  picture; 

3)  to  promote  standardized  appearance  of  drawings. 


37 


•  I 

Figure  13.  A  Typical  Engineering  Drawing  Showing  the  Use  of  Symbols 
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2.3.3  Curves 


Insufficient  time  and  funding  are  available  in  the  present  SOW  to  investigate  this  area  thoroughly. 
For  now,  it  is  assumed  that  the  IGES  entities  represent  a  sufficient  set. 

2.3.4  Hatch  Styles 

A  wide  variety  of  hatch  spiles  are  used  in  engineering  drawings  for  purposes  such  as  representing 
the  nature  of  materials.  Figure  14  illustrates  some  typical  ones.  Insufficient  time  and  funding  are 
available  in  the  present  contract  to  investigate  this  area  thoroughly,  but  based  on  preliminary 
observations,  the  following  capabilities  appear  to  be  needed: 

1)  All  necessary  patterns  available  as  mastered  hatch  styles  (  for  reasons  similar  to  those  stated  for 
marker  symbols  above,  drawings  containing  these  hatch  patterns  cannot  be  transferred  between 
systems  by  decomposing  the  patterns  using  the  individual  primitives  available  in  the  CGM.) 

2)  Arbitrary  fill  areas  and  clipping  regions  are  needed  to  represent  drawings  containing  such  hatch 
patterns.  These  cannot  be  approximated  by  breaking  them  up  into  simpler  areas  since  pattern 
continuity  cannot  be  maintain^ 

[  Note:  Registration  proposals  were  prepared  for  all  types  of  section  lining  (hatch 
styles)  except  the  following,  which  can  be  done  with  a  built-in  hatch  style: 

•  electric  windings,  etc.  hatch  index  6,  horizontal/vertical  crosshatch. 

Registration  proposals  were  prepared  for  the  following  hatch  styles  to  support  the 
more  exact  rendition  requirements  of  the  engineering  drawing  standard  from  a 
similar  type  in  the  built-in  CGM  linestyies.  Hi  each  case,  the  drawing  standard 
requires  "45  degree  lines"  while  the  built  in  batch  styles  guarantee  only  "positive" 
and/or  "negative"  slope. 

•  cast  iron,  etc.  similar  to  hatch  index  3,  positive  slope  equally  spaced 

parallel  lines 

•  white  metal,  etc.  similar  to  hatch  index  6,  positive  slope/negative  slope 

crosshatch] 
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2.3.5  Text 

The  text  capabilities  that  are  actually  required  in  engineering  drawings  are  quite  simple,  although 
most  drawing  systems  provide  more  advanced  features.  This  paragraph  will  first  present  the 
requirements  taken  from  Y14.2M-1979,  and  then  will  describe  the  enhancements  that  are  needed 
to,  for  example,  render  IGES  defined  data  without  loss  of  quality. 

2.3.5.1  Y14.2  Lettering  Requirements 

Single-stroke  Gothic  Lettering 

Lettering  on  drawings  must  be  legible  and  suitable  for  easy  and  rapid  execution.  These 
requirements  are  met  in  the  recommended  single-stroke  gothic  characters  shown  in  Figures  15  and 
16  or  adaptations  thereof,  which  improve  reproduction  legibility.  One  such  adaptation  by  the 
National  Microfilm  Association  is  the  gothic  style  Microfont  alphabet  intended  for  general  usage. 
(See  Figure  17.)  Opaque  and  well-spaced  lettering  is  required  on  the  drawing  for  microfilm 
reproduction. 

Inclined  or  Vertical  Lettering 

Either  inclined  or  vertical  lettering  is  permissible.  Only  one  style  of  lettering  should  be  used 
throughout  a  drawing.  The  preferred  slope  for  the  inclined  characters  is  2  in  5  or  approximately  68 
degrees  with  horizontal.  (See  Figure  16.) 

ABCDEFGHIJKLMNOP  . 
ORSTUVWXYZ& 

1234567890 

Figure  IS.  Vertical  Lettering 
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abcdefchuklmnop  ^ 

ORSTUVWXYZ&  ^ 
1234567890 


Figure  16.  Inclined  Lettering 

ABCDEFGHIJKLMNO 

PQRSTUVWXYZ 


Figure  17.  Microform  Lettering 


Use  of  Upper-case  Letters 

Upper-case  letters  should  be  used  for  all  lettering  on  drawings.  When  additions  or  revisions  are 
ma^,  the  original  style  of  lettering  should  be  maintained. 

Lettering  for  titles,  subtitles,  drawing  numbers,  and  other  uses  may  be  made  free-hand,  by 
typewriter,  or  with  the  aid  of  mechanical  Icnering  devices  such  as  templates  and  lettering  machines. 
Regardless  of  the  method  used,  all  characters  are  to  conform,  in  general,  with  tne  recommended 
gothic  style  and  must  be  legible  in  full  or  reduced  size  copy  by  any  accepted  method  of 
reproduction. 

A  type  face  comparable  to  light-line  Pica  Gothic,  block  numerals  is  preferred  for  typing  on 
drawings. 
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Size  and  Spacing  of  Lettering 

The  recommended  minimum  freehand  and  mechanical  letter  height  for  various  applications  are 
defined  in  the  standards  as  follows: 

Letters  in  words  should  be  spaced  so  that  the  background  areas  between  the  letters  are 
approximately  equal,  and  words  are  to  be  clearly  separated  by  a  space  equal  to  the  height  of  the 
lettering.  For  legible  reproduction,  a  space  between  two  letters  of  at  least  0.06  inch  (1.5  mm)  is  to 
be  used  whenever  possible.  The  space  between  two  numerals  having  a  decimal  point  between  them 
is  to  be  a  minimum  of  two  thirds  the  height  of  the  lettering.  The  vertical  space  between  lines  of 
lettering  should  be  no  more  than  the  height  of  the  lettering,  and  no  less  than  half  the  height  of  the 
lettering  used. 

Notes  should  be  placed  horizontally  on  drawings  and  separated  verrically  by  spaces  at  least  equal  to 
double  the  height  of  the  character  size  used,  to  maintain  the  identity  of  each  note. 

The  division  line  of  a  common  fraction  should  be  parallel  to  the  direction  in  which  the  dimension 
reads  and  should  be  separated  from  the  numerals  by  a  maximum  of  0.06  inch  (1.5  ram)  spacing. 
When  fractions  occur  in  notes,  tables,  and  lists,  the  ctiagonal  division  line  is  permissible.  Numerals 
in  fractions  should  be  the  same  size  as  other  numerals. 

Spacing  between  max/min  dimensions  should  be  one-half  of  the  character  height 

Lettering  should  not  be  underlined  except  when  special  emphasis  is  required.  The  underlining 
should  not  be  less  than  0.06  inch  (1.5  mm)  below  the  lettering. 

The  lettering  height  spacing,  and  proportions  in  Figure  15, 16,  and  17  normally  provide  acceptable 
reproduction  or  camera  reduction  and  blow-back.  However,  manually,  mechanically, 
opti-mechanically,  or  electro-mechanically  applied  lettering  (typewriter,  etc.)  with  height  spacing, 
and  proportions  less  than  those  recommended  are  acceptable  when  the  minimum  reproducibility  and 
legibility  requirements  of  the  accepted  industry  or  tnilitary  reproduction  specifreations  are  met. 
Therefore,  the  basic  requirements  for  lettering  on  a  drawing  is  that  fully  legible  copies  may  be 
produced. 


2.3.5.2  Text  in  IGES 

The  IGES  standard  defines  an  entity  called  general  note  which  consists  of  strings  of  text  that  are 
incorporated  in  other  entities  for  producing  drawing  labels  and  annotation.  IGES  defines  the 
following  fonts  for  use  with  this  entity: 

0.  Symbol  font  (use  longer  recommended) 

1.  Standards  block 

2.  LeRoy 

3.  Future 

4.  Fastfont 

5.  Calcomp 

6.  Comp  80 

7.  Microfilm  standard 

8.  ISO  standard 

9.  DIN  standard 

10.  Military  standard 

1 1 .  Gothic 

12.  .New  gothic 

13.  LightHne  gothic 

14.  Simplex  Roman 

15.  ItaUc 
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16.  APL 

17.  Centuiy  schoolbook 

18.  Helvetica 

1001.  Symbol  font  1 

1002.  Symbol  font  2 

In  addition,  the  IGES  text  model  includes  several  capabilities  that  are  not  present  in  computer 
graphics  standards  such  as  the  CGM.  Appendix  C  contains  extracts  from  the  IGES  standard  that 
explain  these  capabilities. 

IGES  also  includes  a  text  font  definition  entity  that  enables  a  text  font  to  be  described  as  a 
sequence  of  strokes.  Appendix  C  contains  extracts  from  IGES  3.0  that  explain  this  endty.  This 
capability  could  be  built  on  top  of  the  CGM  by  stroking  out  the  individual  characters  as  required.  A 
more  general  solution  to  compatibility  is  described  in  Conclusions  Section,  where  a  common  font 
definition  mechanism  is  proposed,  based  on  ISO  9S41,  for  product  data  standards,  graphics 
standards  and  publishing  standards. 


2.3.6  Images 

Based  upon  review  of  project  descriptions,  CALS  will  capture  and  store  a  great  deal  of  existing 
engineering  drawing  data  in  raster  form.  Neither  the  CGM  nor  IGES  adequately  address  this  area. 
It  is  likely  that  a  solution  developed  for  the  use  of  image  (raster)  data  in  the  publications  area  will 
also  effectively  address  the  requirements  of  engineeiing  drawings. 
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IV.  CONCLUSIONS 
1.0  Introduction 

This  section  presents  the  list  of  extensions  that  are  needed  to  the  COM.  It  is  anticipated  that  most  of 
these  extensions  can  be  implemented  through  the  registration  process.  In  several  areas — as 
described  in  Section  V  below — additional  study  is  necessary  to  determine  the  precise  nature  of  the 
required  extensions. 

NBS/ICST  used  the  following  criteria  in  defining  required  extensions: 

1)  Picture  description  must  be  as  compact  as  is  practical,  consistent  with  ease  of  generation  and 
interpretation.  (This  implies,  in  particular,  that  a  "symbol"  or  "macro"  capabiUty  is  needed,  as  is 
access  to  external  libraries  of  symbols.) 

2)  Only  "presentation-related"  relationships  between  objects  and  attributes  of  objects  need  be 
preserved  in  the  transfer.  (This  places  the  transfer  at  an  intermediate  level  between  that  provided  by 
IGES  and  by  the  (unextended)  CGM.  When  (1)  and  (2)  are  considered  jointly,  they  imply  that 
transfer  by  "approximation  with  lower-level  ^phical  entities" — such  as  approximation  a  curve 
with  a  sequence  of  line  segments  or  a  centerline  with  a  set  of  polylines  an^or  marker  types — is 
unacceptable.  A  local  system  is  free  however  to  make  such  approximations  in  the  process  of 
imaging  a  picture,  consistent  with  accuracy  restrictions.) 

3)  Extensions  must  be  consistent  with  the  philosophical  basis  of  standards  in  the  areas  of  Open 
Systems  Interconnection  (naming  and  addressing  in  particular)  and  Office  Systems  (font 
architecture  in  particular.) 

2.0  Lines 

A  user  defined  linestyle,  similar  to  that  described  in  Section  1.2.1  of  the  Discussion  section  is 
required. 

Linetypes  that  directly  represent  the  presentation  requirements  of  engineering  drawings  must  be 
defin^.  Where  the  limited  capabilities  of  the  built-in  polyline  primitive — which  allows  a  linetype  to 
consist  only  of  a  sequence  of  line  segments  and  gaps,  without  precise  control  over  its 
rendition — are  exceeded,  GDPs  may  be  needed.  Some  conformance  data  may  need  to  be  placed  in 
the  application  profile. 

Some  of  the  types  needed  are: 

1 )  center  line, 

2)  phantom  line, 

3)  break  line, 

4)  lines  with  arrows  on  one  or  both  ends. 

Extensions  to  line  attributes  to  include  line  end  styles  and  joining  options. 

[Note:  A  registration  proposal  for  each  of  those  from  Y14.2M  has  been  written. 
Investigation  of  other  standards  is  needed  to  identify  others.] 


3.0  Symbols 


As  described  above,  the  poljraarker  primitive  is  not  particularly  useful  for  either  publishing  or 
engineering  drawing.  The  registration  of  additional  maiiker  t^es  has  little  utility.  Instead,  a  general 
object  definition  and  instantiation  capability  as  described  is  needed.  [  No  registration 
proposals  have  been  completed  in  this  area.] 


4.0  Curves 

The  following  curves  are  required  as  GDPs.  As  necessary.  Escapes  are  required  to  support  their 
attributes. 

1)  Bezier  curves, 

2)  B-splines, 

3)  Conics  and  conic  arcs, 

4)  Other  splines  as  determined  by  the  study  described  in . 

[Note:  A  registration  proposal  for  each  of  these  has  been  written.] 

A  closed  figure  primitive  is  required,  together  with: 

1)  Arbitrary  clipping  region, 

2)  Arbitraiy  fill  boundary. 

[  No  registration  proposals  have  been  completed  in  this  area.] 

5.0  Hatch  styles 

Registered  hatch  styles  to  support  engineering  drawing  uses  as  defined  in  Section  2.3.4  of  the 
Oiscusion  section  are  required. 

[Note:  A  registration  proposal  for  each  of  those  from  Y14.2M  has  been  written. 

Investigation  of  other  standards  is  needed  to  identify  others.] 

* 

Registered  hatch  styles  to  support  technical  and  administrative  publication  uses  are  required. 
Insufficient  data  is  available  to  specify  these  now. 

6.0  Text 

The  text  model  must  be  completely  replaced  through  the  use  of  GDPs  and  Escapes  to  adopt  the 
model  and  architeemre  of  ISO  DP  9541. 

Some  specific  fonts  identified  in  Section  2.3.5  of  the  Discussion  section  for  use  in  engineering 
drawings  must  be  registered. 

[  No  registration  proposals  have  been  completed  in  this  area.] 
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7.0  Images 


A  raster  "input"  primitive  to  accept  input  from  scanners  and  files  stored  on  disc  (optical  or  not)  is 
required. 

The  role  of  compression  in  the  metafile  must  be  clarified.  Although  it  is  best  to  rely  on  other 
standards  for  necessary  compression,  it  may  be  necessary  to  add  GDPs  to  cover  more  sophisticated 
compression  techniques  in  the  CGM  in  the  shon  term.  The  CCITT  Group  3  and  Group  4  facsimile 
standards  do  not  provide  either  coltn*  or  grey  scale  capabilities. 

Additional  raster  attributes  are  required  to  support  image  processing. 

[  No  registration  proposals  have  been  completed  in  this  area.] 

8.0  Naming  and  External  References 

The  naming  and  definition  of  attributes  and  objects  must  be  extended  from  the  simplistic 
two-dimensional  (positive  and  negative  integer  indices  separating  the  space  into  registered  and 
implementation-dependent  types)  name  space  to  one  consistent  with  the  "resource"  view  of  objects 
seen  in  most  modem  commercial  systems  and  exemplified  in  the  ISO  DP  9541  font  work.  (  A 
limited  attempt  was  made  in  the  CGM  by  including  a  list  of  font  names  that  are  then  mapped  to 
indices.  This  was  a  first  step  in  the  right  direction.)  This  can  be  done  fairly  easily  by  defining 
GDPs  and  Escapes  to  replace  the  existing  output  primitives  and  attributes.  It  is  absolutely 
essential  that  this  be  done  to  insure  the  long>term  coherence  of  information 
processing  standards.  Neither  the  CGM  nor  other  computer  graphics  standards 
will  find  acceptance  in  modern  applications  without  these  extensions. 
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V.  AREAS  REQUIRING  FURTHER  INVESTIGATION 
1.0  Curves 

More  technical  work  is  necessary  to  explore: 

1.  Define  the  actual  requirements  in  the  two  selected  application  areas  for  curves  (  as  opposed  to 
guessing  them  based  on  current  practice. ) 

2.  Investigate  implementation  difficulty  to  determine  the  cost  of  implementation. 

3.  Determine  mathematical  properties  of  conversions  between  curves  (e.g.  loss  of  accuracy,  loss  of 
desired  curvature,  etc.) 

4)  Define  a  minimal  set  of  curves  that: 

a)  have  implementation  difficulty  appropriate  for  various  classes  (price/performance)  of 
systems; 

b)  can  be  readily  used  to  approximate  other  curves. 

To  illustrate  some  of  the  complexities  involved,  the  following  material — provided  by  a  member  of 
the  committee  that  developed  the  IGES  standard — shows  some  of  the  differences  and  similarities 
between  two  curves:  B-splines  and  Bezier  curves. 

Differences  between  B>spHnes  and  Bezier  curves 

1)  Bezier  curve  +  Composite  curve  =  B-spline 

That  is,  the  classes  of  functions  are  in  fact  the  same. 

2)  Commonalities  between  Bezier  curves  and  B-splines 

exact  conics  (rational  quadratics),  though  the  algorithms  for  conic  to  Bezier  (or  B-spline) 
conversions  are  not  in  ^e  public  domain,  to  the  best  of  my  knowledge. 

nonrational  polynomial  curves  of  any  degree. 

nice  mathematical  properties:  convex  hull,  plane  intersection,  etc. 

3)  Bezier 

CO  continuity  can  be  explicit  (common  endpoint). 

Faster  evaluation  (by  divided  differences),  though  not  as  fast  as  power  basis.  Points  and 
deviations. 

Greater  storage  requirements  (deg+l  points  per  segment,  while  B-spline  can  use  Const 
number  of  segments  if  continuity  is  maximal). 

More  stable  (lower  condition  number  than  power  basis  or  B-spline). 

Easy  mathematics:  evaluation,  degree  evaluation,  degree  evaluation,  subdivision. 
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Trivial  conversion  to  B-spline. 

Immediate  evaluation  of  points  and  derivations  at  parametric  start  and  end. 

4)  B-spline 

parametric  continuity  given  explicitly  in  the  knot  sequence.  For  exactness,  prefer  knots 
with  explicit  multiplicity  to  repeated  knots. 

Mathematics  is  quite  complex,  but  powerful:  evaluation,  adding  and  removing  knots. 

For  repeated  evaluation  or  intersection  algorithms,  will  probably  want  to  convert  to 
piecewise  Bezier  first  (this  amounts  to  ma^ng  all  of  the  interior  knots  of  multiplicity 
degree  and  the  two  exterior  knots  of  multiplicity  degree  +  1.) 


2.0  Text 

Additional  time  and  funding  will  be  required  to  develop  and  define  the  new  text  GDP  and 
associated  escapes  (to  implement  attributes)  that  can  fully  implement  the  model  of  ISO  DP  9S41. 
Extensions  to  the  "CGM  environment"  compatible  with  the  ISO  font  description  and  transfer  work 
must  be  developed. 

3.0  Images 

Additional  funding  will  be  required  to  develop  and  define  raster  input  extensions  and  raster  data 
^es  needed  to  fully  suppon  technical  and  adi^strative  publications.  Sporifically,  the  following 
items  are  beyond  the  level  of  the  current  task: 

1.  Definition  of  standard  interfaces  to  input  scanning  devices  through  the  CGI/CGM  and  GKS. 

2.  Expansion  of  the  attributes  of  raster  data  to  accommodate  the  requirements  of  image  processing 
algorithms.  For  example,  data  is  needed  on  the  characteristics  of  input  scanner  (resolution, 
ft^uency  response  characteristics,  etc.)  to  properly  process  the  data. 

3.  Families  of  standard  compression  algorithms  must  be  developed  beyond  those  currently 
supponed  in  MIL-STD-1840  (Automated  Interchange  of  Technical  Information.)  The  one 
algorithm  in  that  standard  (CCITT  group  4  facsimile)  as  well  as  the  one  compression  technique 
supported  in  the  CGM  (a  one-dimensional  run-length  encoding  vaguely  similar  to  Group  3 
facsimile)  are  well  known  to  be  inadequate  for  "photographic”  content,  "ftese  techniques  are  useful 
for  rasterized  text  and  geometric  graphics,  however  these  contents  would  most  likely  be 
"compressed"  by  sending  them  in  a  CGM  or  ODIF  format.  The  CGM  can  be  easily  extended  with 
additional  raster  primitive/sencodings,  thereby  completely  removing  the  requirement  for  the 
inclusion  of  Group  4  facsimile  in  MIL-STD- 1 840. 

4.0  Specification  of  Data  Record  Contents 

Escapes,  GDPs,  and  Application  data  all  contain  information  in  data  records.  The  standards  do  not 
dictate  how  data  in  such  records  must  be  formulated  or  encoded.  It  is  desirable  that  a  standard 
method  be  developed  for  all  of  these  data  records  and  promulgated  throughout  the  standards 
community  with  the  intention  that  all  registration  proposals  use  this  same  standard  method.  At 
present,  we  are  specifying  a  "clear  text"  encoding  only  for  all  data  records.  This  is  clearly 
inadequate  to  support  binary  coded  transfer  of  complex  drawings  due  to  compactness 
considerations. 
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5.0  Support  for  Named  Items  and  "Symbol  Libraries” 

Extensions  must  be  developed  to  replace  the  simplistic  “indexed"  definition  of  attributes  in  the 
graphics  standards  with  named  definitions  based  on  a  resource  model  consistent  with  that  of  the 
ISO  Font  standard.  Techniques  must  be  developed  to  allow  picture  components  (symbols,  macros) 
to  be  defined  and  instantiate  in  pictures. 

6.0  Definition  of  Registration  Requirements  and  Development  of  Registration 
Proposals 

Additional  work  will  be  required  to  complete  the  definition  of  registration  requirements  and  the 
development  of  registration  proposals  in  these  areas: 

1)  Linetypes, 

2)  Hatchstyles, 

3)  Text  fonts. 

This  is  due  to  these  factors: 

1)  The  large  number  of  registration  proposals  to  be  developed. 

2)  The  long  time-frame  involved  in  sponsoring  registradon  proposals  through  the  approval  process 
and  preparing  necessary  revisions  and  responedng  to  comments  from  standa^  committees. 

3)  The  need  for  a  review  of  proposed  items  by  the  CALS  community. 
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VL  RECOMMENDATIONS 
1.0  Registration  Proposals  List 


Recommendations  for  this  task  are  the  registration  proposals  themselves.  The  following  list 
contains  the  categories  and  the  names  of  ^e  registration  proposals  developed  under  this  CALS 
SOW  task.  They  have  been  submitted  to  ANSI  for  formal  processing  through  ISO.  Section  2.0 
below  contains  the  actual  registration  proposals  that  have  been  developed  and  submitted  for  this 
fiscal  year,  and  are  in  the  oider  as  listed  below. 

1)  Linetypes 

break  line  -  style  1 
break  line  -  style  2 
center  line 
chain  line 
double  arrow 
hidden  line 
phantom  line 
single  arrow 
single  dot 
stitch  line 

user  specified  dash  pattern 

2)  Hatchstyles 

across  grain  wood 

bronze,  brass,  copper,  and  compositions 

cast  iron  or  mailable  iron  and  general  use  for  all  materials 

concrete 

cork,  felt,  fabric,  leather,  and  fiber 
earth 

magnesium,  aluminum,  and  aluminum  alloys 

marble,  slate,  glass,  procelain,  etc. 

rock 

rubber,  plastic,  and  electrical  insulation 
sand 

sound  installation 
steel 

thermal  insulation 

titanium  and  refractory  material 

water  and  other  liquids 

white  metal,  zinc,  lead,  babbitt,  and  alloys 

with  grain  wood 

3)  Generalized  drawing  primitives 

Bezier  curve 
conic  arc 

parametric  spline  curve 
rational  B-spIine  curve 

4)  Escape  functions 

set  conic  arc  transformation  matrix 

set  dash 

set  line  cap 

set  line  join 

set  miter  limit 
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2.0  Prepared  Registration  Proposals 

following  registration  proposals  are  exacdy  as  submitted  to  ANSI  for  formal  registration. 
/  have  all  been  submit^  and  are  currendy  in  the  formal  process. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  linettpi 


Name:  brealc  line  -  style  1 


description:  ^  break  line  linetype  —style  1—  consists  of  either  one  of  two  allowable 
representations  as  specified  in  ANSI  yi4.2M-1979  (Line  Conventions 
and  Lettering.!  This  is  simply  a  line  having  a  "freehand”  appearance. 


This  linetype  is  intended  for  use  in  engineering  drawings . 


Additional  Comments:  The  requirements  stated  in  ANSI  Y14.2M-197  9  shall  be  followed 

when  rendering  this  linetype. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linotypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  lO  April  1387 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  lzhbttpb 


Name:  breaJc  line  -  style  2 


Description:  ^  break  line  linestyle  consists  of  either  one  of  two  allowable 

representations  as  specified  in  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering.)  This  is  a  line  consisting  of  long  dashes  joined  by 
zigzags.  Such  lines  have  the  following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings . 


Additional  Comments:  The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  when 

rendering  this  linetype. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  lzkstypb 


Description:  ^  center  line  linetype  consists  of  alternating  long  and  short  dashes  as 
specified  in  ANSI  Y14.2M-1979  (Line  Conventions  and  Lettering.)  Such  a 
line  has  the  following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings.  The  long 
dashes  may  vary  in  length  depending  on  the  size  of  the  drawing.  Lines 
drawn  in  this  linetype  shall  start  and  end  with  long  dashes.  A  very 
short  line  may  de  unbroken. 


Additiooal  Comments:  The  requirements  stated  xn  ANSI  yi4.2M-197  9  shall  be  followed 

when  rendering  this  linetype. In  some  cases,  it  is  necessary  to 
exercise  precise  control  over  the  manner  in  which  two  center 
lines  intersect  in  a  drawing.  In  these  cases,  it  is  appropriate 
to  3i’“ulate  this  linetype  by  sequences  of  correctly  placed 
individual  line  segments . 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linotypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  lznstype 


Description:  ^  chain  line  linetype  consists  of  alternating  long  and  short  dashes 
as  specified  in  ANSI  Y14.2M-1979  (Line  Conventions  and  Lettering.) 
Such  a  line  has  the  following  visual  appearance; 


This  linetype  is  intended  for  use  in  engineering  drawings.  Its  rendition 
is  generally  different  from  that  of  the  dashed-dotted  linestyle  already 
present  in  the  graphics  standards. 


Additional  Comments:  The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed 

when  rendering  this  linetype.  In  some  cases,  it  is  necessary  to 
exercise  precise  control  over  the  manner  in  which  two  lines  inter¬ 
sect  in  a  drawing.  In  these  cases  it  may  be  appropriate  to 
simulate  this  linetype  by  using  sequences  of  correctly  placed 
individual  line  seqments. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  0632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  lxmxttpb 


Name:  double  arrow 


Description:  ^  double  arrow  linecype  consists  of  a  solid  line  terminated  by  two 
arrowheads  as  specified  in  ANSI  V14.2H-1979  (Line  Conventions  and 
Lettering)  requirements  for  dimension  lines.  The  arrows  are  rendered  so 
that  the  arrow  tip  occurs  at  the  first  and  last  points  in  the  defining 
set.  Such  a  line  has  the  following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings . 


Additional  Comments:  .j^e  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed 

when  rendering  this  linetype. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linotypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
cc.Tipact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards; 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  t.hcse 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  lzmbtypc 


Name:  hidden  line 


Description:  ^  hidden  line  linetype  conaiata  of  short  evenly  spaced  daahea  aa  specifiec 
in  ANSI  Y14.2M-1979  (Line  Conventions  and  Lettering.)  Such  a  line  has  the 
following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings.  The  dashes  may 
vary  in  length  depending  on  the  size  of  the  drawing.  Lines  drawn  in  this 
linetype  shall  start  and  end  with  a  dash.  Dashes  shall  join  at  corners, 
and  arcs  drawn  with  this  style  shall  start  and  end  with  dashes .  These 
rendition  requirements  are  different  from  the  dashed  linetype  that  is 
already  defined  in  the  graphics  standards. 


Additional  Comments:  The  requirements  stated  in  ANSI  yi4.2M-1979  shall  be  followed  when 

rendering  this  linetype.  In  some  cases,  it  is  necessary  to  e-xer- 
cise  precise  control  over  the  manner  in  which  two  lines  intersect 
in  a  drawing.  In  these  cases  it  may  be  appropriate  to  simulate 
this  linetype  by  using  sequences  of  correctly  placed  individual 
line  seoments. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  preseniaiion  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  lzmetypc 


Name:  phantom  line 


Description:  ^  phantom  line  linetype  consists  of  long  dashes  separated  by  pairs 
short  dashes  as  specified  in  ANSI  yi4.2M-1979  (Line  Conventions  and 
Lettering.)  Such  a  line  has  the  following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings .  The  long 
dashes  may  vary  in  length  depending  on  the  size  of  the  drawing.  Lines 
drawn  in  this  linetype  shall  start  and  end  with  long  dashes  which  may 
vary  in  length  oepending  on  the  size  of  the  drawing. 


Additional  Comments:  The  requirements  stated  in  ANSI  Z14.2M-1979  shall  be  followed 

when  rendering  this  linetype.  In  some  cases,  it  is  necessary  to 
exercise  precise  control  over  the  manner  in  which  two  lines  inter¬ 
sect  in  a  drawing.  In  these  cases  it  may  be  appropriate  to  si.mula: 
this  linetype  by  using  sequences  of  correctly  placed  individual 
line  seoments. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  1C  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  limettpc 


Name:  single  arrow 


Description:  ^  single  arrow  linetype  consists  of  a  solid  line  terminated  by  an 
arrowhead  as  specified  in  ANSI  Y14.2M-1979  (Line  Conventions  and 
Lettering)  requirements  for  dimension  and  leader  lines .  The  arrow  is 
rendered  so  that  the  arrow  tip  occurs  at  the  last  point  in  the  defining 
set.  Such  a  line  has  the  following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings. 


Additional  Comments:  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed 

when  rendering  this  linetype. 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  lxmsttps 


Name:  single  dot 


escnption:  ^  single  dot  linetype  consists  of  a  solid  line  terminated  by  a  dot 
as  specified  in  ANSI  yi4.2M-1979  (Line  Conventions  and  Lettering) 
requirements  for  leader  lines.  The  dot  is  rendered  so  that  the  dot 
occurs  at  the  last  point  in  the  defining  set.  Such  a  line  has  the 
following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings . 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  when  rendering  this 
linetype. 


JustiHcation  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  lzmsttpi 


Description:  ^  stitch  line  linetype  consists  of  dashes  and  spaces  of  equal  length 
as  specified  in  ANSI  Y14.2M-1979  (Line  Conventions  and  Lettering.) 
Such  a  line  has  the  following  visual  appearance: 


This  linetype  is  intended  for  use  in  engineering  drawings.  Its  definition 
contains  rendition  requirements  beyond  those  for  the  dashed  linetype 
already  present  in  the  graphics  standards. 


Additional  Comments:  The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  when 

rendering  this  linetype.  In  some  cases,  it  is  necessary  to  exer¬ 
cise  precise  control  over  the  manner  in  which  two  lines  intersect 
in  a  drawing.  In  these  cases  it  may  be  appropriate  to  simulate 
this  linetype  by  using  sequences  of  correctly  placed  individual 
line  seoments . 


Justification  for  Inclusion  in  the  Register: 

This  linetype  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
linetypes  to  be  registered  for  use  with  computer  graphics  standards  to  enable 
compact  storage  and  transfer  of  engineering  drawings. 


Rslationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
def i.ned  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  linktypb 


Name:  user-specified  dash  pattern 


escription: 

The  user-specified  dash  pattern  linetype  consists  of  alternating  dashes  and  spaces 
as  specified  in  the  current  user-specified  linetype.  This  linetype  is  intended 
for  use  in  high-quality  graphical  applications  where  the  user  of  the  standard 
maintains  precise  control  over  the  manner  in  which  the  linetype  is  rendered  by 
the  use  of  individually  specified  attributes.  Although  its  use  is  not  precluded  in 
applications  that  choose  to  use  bundled  attributes,  the  intent  of  the  user  to 
exercise  a  high  degree  of  control  over  the  rendition  of  graphical  output  will  be 
compromised,  especially  in  metafile  applications. 


Additional  Comments: 

This  registration  proposal  is  accompanied  by  a  proposal  to  register  an  escape  fu.nc- 
tion  -Set  Dash-  for  the  CGM  that  defines  the  current  user-specified  linetype.  It  is 
intended  that  these  proposals  be  processed  together. 


Justification  for  Inclusion  in  the  Register: 

User  specified  linetypes  are  needed  to  support  the  requirements  of  office  document 
exchange  and  publishing.  They  are  commonly  found  in  widely  available  proprietary 
graphics  systems. 


Relationship  to  Particular  Standards: 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those 
defined  in  5.7.2. 


73 


This  page  left  intentionally  blank. 


74 


PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


I 


I  Class  of  Graphical  Item:  hatchstylc 

Name:  across  grain  wood 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Convention 
and  Lettering)  for  the  representation  of  across  grain  wood  in  engineering 
drawings.  The  intended  visual  representation  of  a  filled-area  element  hatched  in 
this  style  is  illustrated  below: 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  thus 
linetype . 


JustiCication  for  Inclusion  in  the  Register: 


s 


This  hatchstyle  is  commonly  used  in  engineering  drawings .  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized.  , 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  batchsttli 


Name:  bronze,  brass,  copper,  and  compositions 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  yi4.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  bronze,  brass,  copper,  and  compositions 
in  engineering  drawings.  The  intended  visual  representation  of  a  filled-area 
element  hatched  in  this  style  is  illustrated  below: 


Additional  Comments: 


The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype . 


Justification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchtypes  registered  for  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


dais  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  AMS  I 


Class  of  Graphical  Item:  batchstylk 


Name:  cast  iron  or  malleable  iron  and  general  use  for  all  materials 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  -  representation  of  cast  iron  or  malleable  iron  and  general 
use  for  all  materials  in  engineering  drawings.  The  intended  visual  representation 
of  a  filled-area  element  hatched  in  this  style  is  illustrated  below: 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype.  These  requirements  are  different  from  those  for  CGM  linetype  3,  which 
requires  only  positive  slope  lines  rather  than  45  degree  lines. 


Justification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


Reiationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal 


10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  batchstylk 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  concrete  sections  in  engineering  drawings 
The  intended  visual  representation  of  a  filled-area  element  hatched  in  this  style 
is  illustrated  below: 


,  0  ^ 

t>  ^  a 

D-  o- 

O  ^  o 


Additional  Comments: 


The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype . 


Justification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  ccrpac 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represe.n- 
tation  of  the  attributes  of  filled  areas  in  engineering  drawi.ngs  is  widely 
recognized. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 


81 


This  page  left  intentionally  blank. 


82 


PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  hatcrsttlk 


Name:  cork,  felt,  fabric,  leather,  and  fibre 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  cork,  felt,  fabric,  leather,  and  fibre  ir 
engineering  drawings.  The  intended  visual  representation  of  a  filled-area  element 
hatched  in  this  style  is  illustrated  below: 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  when  rende: 
linetype . 


Justification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  repre¬ 
sentation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  batchstylk 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-’979  (Line  Conventions 
and  Lettering)  foe  the  representation  of  earth  sections  in  engineering  drawings. 
The  intended  visual  representation  of  a  filled-area  element  hatched  in  this  style 
is  illustrated  below; 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype. 


Justification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  tf  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  corr.pac 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  videiy 
recognized. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

1  2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presenution  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


lass  of  Graphical  Item:  hatchstyx.1 


ime:  magnesiuin,  aluminuin,  and  alurninurn  alloys 


escription: 

A  hatchstyle  conforming- to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  magnesium,  aluminum,  and  aluminum  alloys 
in  engineering  drawings.  The  intended  visual  representation  of  a  filled-area 
element  hatched  in  this  style  is  illustrated  below: 


dditionai  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype . 


istification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


elationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presenution  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


lass  of  Graphical  Item:  hatcrstyli 


ime:  marble/  slate,  glass,  porcelain,  etc. 


escription: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  marble,  slate,  glass,  porcelain,  etc.  in 
engineering  drawings.  The  intended  visual  representation  of  a  filled-area  element 
hatched  in  this  style  is  illustrated  below: 


dditiooal  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype. 


istification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


elationship  to  Particular  Standards: 


1) 

ISO 

7942 

(GKS)  -  Specifies 

2) 

ISO 

8632 

(CGM)  -  Specifies 

registered  hatch  style  as 
registered  hatch  style  as 


defined  in 
defined  in 


5.4.1. 

5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


iss  of  Graphical  Item:  hatchstyli 


ne:  roclc 


icription: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  rock  sections  in  engineering  drawings. 
The  intended  visual  representation  of  a  filled-area  element  hatched  in  this  style 
is  illustrated  below: 


ditiooal  Comments: 


The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype . 


tification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


lationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 


This  page  left  intentionally  blank. 


92 


PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal 

10  April  1987 

sponsoring  authority  ANSI 

ass  of  Graphical  Item:  hatchstyli 


me:  rubber,  plastic,  and  electrical  insulation 


scription: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  rubber,  plastic,  and  electrical  insulatiori 
in  engineering  drawings.  The  intended  visual  representation  of  a  filled-area 
element  hatched  in  this  style  is  illustrated  below: 


ditional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  t.his 
linetype . 


itirication  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


iationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defi.ned  in  5.4.1. 

2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal 

10  April  1987 

sponsoring  authority  ANSI 

5S  of  Graphical  Item:  batcbstylk 


le:  sand 


cription: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  sand  sections  in  engineering  drawings . 
The  intended  visual  representation  of  a  filled-area  element  hatched  in  this  style 
is  illustrated  below: 


litional  Comments: 

The  requirements  stated  in  ANSI  yi4 .2M-1979shall  be  followed  in  rendering  this 
linetype . 


;irication  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


ationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

2)  ISO  0632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


is  of  Graphical  Item:  hatcrstyli 


c  sound  insulation 


ription: 

hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
ind  Lettering)  for  the  representation  of  sound  insulation  in  engineering 
Irawings.  The  intended  visual  representation  of  a  filled-area  element  hatched  in 
:his  style  is  illustrated  below: 


itiooal  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  inrendering  this 
linetype. 


ification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized . 


itionsbip  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentadon  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  batcrstylb 


Name:  steel 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  steel  sections  in  engineering  drawings. 
The  intended  visual  representation  of  a  filled-area  element  hatched  in  this  style 
is  illustrated  below: 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  this 
linetype . 


Justincation  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings .  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compac 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (CGM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal 

10  April  1987 

sponsoring  authority  ANSI 

Class  of  Graphical  Item:  HATcasTyx.1 


Same:  chemal  insulation 


Description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  thermal  insulation  in  engineering 
drawings.  The  intended  visual  representation  of  a  filled-area  element  hatched  in 
this  style  is  illustrated  below: 


Additional  Comments: 

The  requirements  stated  in  ANSI  yi4.2M-1979  shall  be  followed  in  rendering  this 
linetype . 


Justification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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proposal  for  registration  of  graphical  item 


date  of  presenution  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  hatchstylk 


Same:  titanium  and  refractory  material 


description: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Convent: 
and  Lettering)  for. the  representation  of  titanium  and  refractory  material 
in  engineering  drawings.  The  intended  visual  representation  of  a  filled-area 
element  hatched  in  this  style  is  illustrated  below: 


Additional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in  rendering  thi- 
iinetype. 


fustification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings .  It  is  one  of  a  set  o 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 


2)  ISO  8632  (COM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  registration  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal 

10  April  1987 

sponsoring  authority  ANSI 

ass  of  Graphical  Item:  HATcasTYLK 


me:  water  and  other  liquids 


scription: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  water  and  other  liquids  in  engineering 
drawings.  The  intended  visual  representation  of  a  filled-area  element  hatched  in 
this  style  is  illustrated  below: 


ditionai  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  take  precedence  over  those  in  this 
proposal  in  case  of  a  conflict. 


stincation  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compac 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized . 


ilationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


!Iass  of  Graphical  Item:  hatchstyls 


ame:  white  metal,  zinc,  lead,  babbitt,  and  alloys 


escriptioa: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  white  metal,  zinc,  lead,  babbitt,  and 
alloys  in  engineering  drawings.  The  intended  visual  representation  of  a  filled- 
area  element  hatched  in  this  style  is  illustrated  below; 


dditional  Comments: 

The  requirements  stated  in  ANSI  yi4.2M-1979  Shall  be  followed  in  rendering  this 
linetype.  These  requirements  are  different  from  those  for  CGM  linetype  6,  which 
requires  only  positive  and  negative  slope  lines  rather  than 
45  degree  lines . 

ustification  for  Inclusion  in  the  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  for  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a 

2)  ISO  8632  (CGM)  -  Specifies  a 


registered  hatch  style  as 
registered  hatch  style  as 


defined  in 
defined  in 


5.4.1. 

5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presenution  of  proposal 

10  April  1987 

sponsoring  authority  ANS I 

lass  of  Graphical  Item:  hatchstylx 


ame:  with  grain  wood 


escriptioo: 

A  hatchstyle  conforming  to  the  requirements  of  ANSI  Y14.2M-1979  (Line  Conventions 
and  Lettering)  for  the  representation  of  with  grain  wood  in  engineering 
drawings.  The  intended  visual  representation  of  a  filled-area  element  hatched  in 
this  style  is  illustrated  below: 


dditional  Comments: 

The  requirements  stated  in  ANSI  Y14.2M-1979  shall  be  followed  in^ rendering  this 
linetype . 


astincatioD  for  Inclusion  in  tbe  Register: 

This  hatchstyle  is  commonly  used  in  engineering  drawings.  It  is  one  of  a  set  of 
hatchstyles  registered  use  with  computer  graphics  standards  to  enable  compact 
storage  and  transfer  of  engineering  drawings.  The  need  for  a  compact  represen¬ 
tation  of  the  attributes  of  filled  areas  in  engineering  drawings  is  widely 
recognized. 


telationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  hatch  style  as  defined  in  5.4.1. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  hatch  style  as  defined  in  5.7.24. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presenucion  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


ass  of  Graphical  Item:  GDP 


•P  Identifier:  Bezier  curve 

icription: 

A  Bezier  cubic  section  is  generated  using  the  four  points  specified.  The  curve 
starts  at  the  first  point  and  ends  at  the  fourth  point;  the  second  and  third  point 
are  used  as  control  points.  See  the  attached  sheets  for  more  details. 


ditional  Comments: 

The  Bezier  curve  capabilities  proposed  here  are  adapted  from  those  in  the 
PostScript  language  developed  by  Adobe  Systems  Incorporated. 

tification  for  Inclusion  in  the  Register: 

Bezier  curves  are  needed  to  support  the  requirements  of  office  document  exchange 
and  publishing.  They  are  commonly  found  in  proprietary  widely  available  graphics 
systems . 


ationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  GDP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  GDP  as  defined  in  5.6.10. 

3)  ISO  8651^  (GKS  Language  Bindings)  -  Specifies  a  registered  GDP. 

(see  attached  sheets) . 


'At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is 
provisional  until  this  standard  has  been  approved  by  ISO  council. 


Ill 


1)  CGM  Functional  Spacification  (reference  ISO  8632  COM; 

Part  1:  Functional  Description) 

Baziar  curva  adds  a  Bezier  cubic  curve  between  the  first  point, 
referred  to  here  as  and  the  fourth  point  (X,,  F,)  ,  using 

{X,,  Y,)  and  (X^,Y^)  as  the  Bezier  cubic  points. 

The  four  points  define  the  shape  of  the  curve  geometrically.  The 
curve  starts  at  Y^) ,  it  is  tangent  to  the  line  from  (X^,  Y^)  to 

(X^,  Xj)  at  that  point,  and  it  leaves  the  point  in  that  direction. 

The  curve  ends  at  (X^,  Y^)  ,  it  is  tangent  to  the  line  from(  X^,  Y.) 

to  (Xj,  Xj)  at  that  point,  and  it  approaches  the  point  from  that 

direction.  The  lengths  of  the  lines  (X^,  X^)  to  (X,,  X,)  and 

(X^,  X^)  to  (Xj,  Yj)  represent  in  some  sense  the  "velocity"  of  the 

path  at  the  endpoints.  The  curve  is  always  entirely  enclosed  by  the 
convex  quadrilateral  defined  by  the  four  points. 

The  mathematical  foundation  of  a  Bezier  cubic  curve  is  derived  from 
a  pair  of  parametric  cubic  equations: 

x(t)  »  +  c^r  -*■  Xg 

y(t)  -  a^t-^  +  c^t  +  y- 

The  cubic  section  produced  by  B«zi«r  curve  is  the  path  traced 
x(t)  and  y(t)  as  t  ranges  from  0  to  1.  The  Bezier  control  poi.t 
corresponding  to  this  curve  are: 

^1  "  ^0  *  Yi  ^  Yo  * 

>  (c^  +  bJ/3  Y2  =  Yi  (c  .  +  b^)/3 

X,  =  xg  t  c^  ^  t  y^  =  y,  *  ^  b^  ^  a^. 
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A  functional  description  of  the  Bezier  curve  generalized  drawing 
primitive  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Regist rat -cn 

Authority 

point  list  (nP) 
data  record (D) 


Items  for  Data  Record: 

Integer  IL  0 

Integer  RL  0 

Integer  SL  0 

Data  Record  Description: 

The  data  record  is  empty. 


2)  C6M  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

I 

I  All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 

encoding  (machine  independent)  of  a  FORTRAN-style  packed  data 
record.  This  is  treated  as  a  string  .type  in  each  encoding  and  is 
encoded  according  to  the  rules  for  string  in  that  enccding. 
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PROPOSAL  FOR  registration  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  GDP 


GDP  Identifier:  conic  arc 


Description: 

A  bounded  connected  portion  of  a  parent  conic  curve  is  generated  in  a  definition 
space  and  then  transformed  to  world  coordinates  by  the  current  conic  arc  transfc 
ation  matrix.  The  intended  realization  of  this  output  primitive  is  equivalent  to 
that  intended  for  the  Conic  Arc  Entity  of  IGES  Version  3.0.  See  the  attached 
sheets  for  more  details. 


Additional  Comments:  None 


Justification  for  Idciusion  in  the  Register: 

Conic  arcs  are  needed  to  support  the  requirements  of  office  document  exchange, 
publishing,  and  engineering  drawing  exchange.  They  are  commonly  found  in 
proprietary  graphics  systems.  The  conic  arc  capabilities  proposed  here  are  adcpte 
from  the  ANSI  Y14.26  (IGES  Version  3.0)  specification. 


Relationship  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  GDP  as  defined  in  5.3. 

2)  ISC  8632  (CGM)  -  Specifies  a  registered  GDP  as  defined  in  5.6.10. 

3)  ISO  8651"  (GKS  Language  Bindings)  -  Specifies  a  registered  GDP. 

(see  attached  sheets) . 


‘At  present  at  the  stage  of  draft.  The  status  of  t.his  relationship  is 
provisional  until  this  standard  has  been  approved  by  ISO  council. 


1)  CQ<  Functional  3paclficatlon  (reference  ISO  8632  COM; 

Part  1:  Functional  Description) 

The  conic  arc  is  a  realization  of  the  Conic  Arc  Entity  of  the 
IGES  3.0  standard.  The  attached  extracts  from  the  IGES  Version  3.0 
standard  provide  the  functional  specification. 

A  functional  description  of  the  conic  arc  para.meters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list(nP)  -  contains  the  two  start  and  terminate  points 
data  record  (D) :  -  see  the  IGES  attachments  for  definitions 

A. 

•  B 
C 
D 
E 
F 

Note:  The  ZT  value  is  not  included  since  it  must  be  zero. 

Items  for  Data  Record: 


The  following  values  are  in  the  same  order  as  in  the  IGES  standard. 


Integer  IL  0 
Integer  RL  6 
Real  RA(1)  A 
Real  RA(2)  B 
Real  RA<3)  C 
Real  RA{4)  D 
Real  RA(5)  E 
Real  RA(6)  F 
Integer  SL  0 


Data  Record  Description: 

The  parameters  are  as  defined  in  the  attached  extract  from  the 
IGES  standard. 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTRAN-st  y  le  paciced  data 
record.  This  is  treated  as  a  string  type  in  each  encoding  and  ts 
encoded  according  to  the  rules  for  string  in  that  encoding. 


104  -  CONIC  ARC 


3.A  Conic  Are  Entity 

A  conic  are  is  •  bounded  connected  portion  of  s  parent  conic  curve  which 
consists  of  more  than  one  point.  The  parent  conic  curve  is  either  an  ellipse,  a 
paraboU,  or  a  hyperboU.  The  definition  space  coordinate  system  is  always 
ehoaen  so  that  the  conic  are  lies  in  a  plane  either  coincident  with  or  parallel 
to  the  XTt  YT  plane.  Within  such  a  plane,  a  conic  is  defined  by  the  six 
coefficients  in  the  following  equation. 

A*XT^  ♦  B*XT*YT  ♦  C*YT^  •►0*XT  ♦  B*YT  *  F  •  0 

3.A.1  Each  coefficient  is  a  real  number.  The  definitions  of  ellipse,  parabola,  and 

hyperbola  in  terms  of  these  six  coefficients  ve  given  below. 

3.4.2  A  conic  arc  determines  unique  are  endpoints.  A  conic  are  is  defined  within 
definition  space  by  the  six  ceefficients  above  and  the  two  endpoints,  fty 
conaidering  the  conic  are  endpoints  to  be  enumerated  and  listed  in  an  ordered 
manner,  start  point  followed  by  terminate  point,  a  direction  with  respect  to 
definition  «pace  can  be  associated  with  the  are.  In  order  for  the  desired 
elliptical  are  to  be  distinquished  from  its  complementary  clliptieal  are,  the 
direction  of  the  desired  eliiptieal  are  must  be  counterclockwise.  In  the  ease 
of  a  parabola  or  hyperbola,  the  parameters  given  in  the  parameter  data 
section  uniquely  define  a  portion  of  the  parabola  or  a  portion  of  a  branch  of 
the  hyperbola;  therefore,  the  concept  of  a  countareloekwise  direction  is  net 
applied.  (Refer  to  Section  3.1.2  for  information  concerning  use  of  the  term 
"counterclockwise  J 

3.4.3  The  direction  of  the  conic  arc  with  respect  to  model  space  is  determined  by 
the  origirtal  direction  of  the  are  within  definition  space,  in  conjimction  with 
the  action  of  the  transformation  matrix  on  the  are. 
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.  COHIC  ARC 


3.A.A  The  definitions  of  the  terms  ellipse,  perebote,  end  hyperbole  ere  given  in  terms 
of  the  quentities  Ql,  Q2,  end  Q3.  These  quentiues  ere: 


Ql  m  qeienBiaiBi  of 


A  Bn  on 
Bn  c  m 
on  on  T 


02 


A 

Bn 


Bn 

c 


03  -  ^  -r  C 


3.A.3  A  pertnt  conic  cjrve  is 

An  ellipse  if  Q2X  end  Ql  *  Q3<0. 

A  hyperbeU  if  Q2<0  end  Ql  4  0. 

A  perebele  If  Q2  >  0  end  Ql  ^  0. 

An  example  of  each  type  of  conic  are  is  shewn  in  Rgurc  ^3. 

3.4.6  These  entities  which  can  be  represented  as  various  degenerate  forms  of  a  conic 
equation  (Point  and  Line)  must  net  be  put  into  the  Entity  Type  104;  mere 
appropriate  Entity  Types  exist  for  these  forms. 


Because  of  the  numerical  sensitivity  of  the  implicit  form  of  the  conic 
description,  a  receiving  system  not  using  that  form  as  its  internal  representation 
for  conics  need  not  be  expected  to  correctly  process  conics  in  this  form  isiiess 
they  are  put  into  a  standard  position  in  definition  space.  A  conic  arc  entity  is 
said  to  be  in  a  standard  position  in  definition  space  provided  each  of  its  axes  is 
paraiicl  to  either  the  XT  axis  or  YT  axis  and  provided  it  is  centered  about  the  ZT 
axis.  For  a  parabola,  use  the  vertex  as  the  origin.  The  conic  is  moved  from  this 
*  position  in  definition  space  to  the  desired  position  in  space  with  a  transformation 
matrix  (Entity  type  124). 


The  form  number  is  regarded  as  purely  informational  by  such  a  postprocessor. 
Piether  details  may  be  found  in  Appendix  E. 


117 


118 


10U  -  CONIC  ABC 


3.A.7 


In  the  event  that  a  parameterization  is  required  but  not  given,  the  delauJt 
parameterization  is: 


Parabola 


ease  A  and  E  /  0.0 
if  XI  <  X2 

C(t)  «  (t,  -<A/E}*f2,  m 
where,  lor  i  ■  1  and  2,  ti  ■  Xi. 

if  X2  <  XI 

C(t)  «  {-t,  .(A/E)*f2,  2T) 
where,  lor  i  a  1  and  2,  ti  a  -Xi. 

case  C  and  0  X  0.0 

il  Yl  4  Y2 

c(t)  a  t,  m 

where,  lor  i  a  1  and  2,  ti  a  Yi. 
il  Y2  <  Yl 

C(t)  a  (-(C/0)*t*»2,  -t,  2T) 
where,  lor  i  a  1  and  2,  ti  a  -Yi. 


lor  tl  4  t  4  t2 


lor  tl  4  t  4  t2 


lortl4  t  ^t2 


lor  tl  ^  t  4  t2 


ElUose 

C{t)  a  (a*eoa  t,  b»sin  t,  2T) 
lor  ti  <  t  4  t2 


where 

a  a  sqrt{-F/A) 
b  a  sqrt(-F/C) 

and,  lor  i  a  1  and  2,  ti  is  such  that 

(i)  (a*cos  ti,  b*sin  ti,  ZT)  a  (Xi,  Yi,  ZT) 
Ui)  0  4  ti  4  2*n 
Uu)  04t2-tl4  2*PI 


Hyperbola 

case  F*A  <  0.0  and  F*C  >  0.0 
let 

a  a  sqrt(-F/A) 
b  a  sqrt(F/C) 
and,  lor  i  a  1,2 
ti  is  such  that 

a)  {a*see  ti,  b*tan  ti,  ZT)  a  (Xi,Yi,ZT) 
Gi)  -  PI/2<tI,t2<Pl/2 
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10«  -  COMIC  ARC 


if  tl  <  t2 

C(t)  a  (a*scc  t,  b^tan  t,  ZT)  lor  1  ^  t  ^  t2 

ilt2<ti 

C(t)  •  (•♦locl-t),  b*t»n(-t),  ZT)  lor  -ti  ^  t  ^  -t2 

COM  F*A  >  OJ)  and  P*C  <  0.0 
lot 

a  ■  sqrt(F/A) 
b  «  s4rt(>P/C) 
and,  lor  i  a  1,2 
ti  is  such  That 

G)  (a*tan  ti.  b*i«:  ti.  ZD  a  (Xi,ri.ZD 
Gi)  -  R/2  <tl,t2  <PI/2 

iftl^t2 

C(t)  a  (a*ta:i  t,  b*s«c  t,  ZT)  lor  tl  ^  t  ^  t2 

if  t2  <  tl 

C(t)  a  (a*tan(-t),  b*s«e<-t),  ZT)  lor  •tl  ^  t  ^  -t2 

3.4.1  Field  13  of  the  directory  entry  accommodates  a  Form  Number.  For  this  entity, 
the  options  are  as  loliotes: 

FORM  Msssisc 

0  Form  of  parent  conic  curve  must  be  determined  from  the  general 

equatioru 

1  Parent  conic  cirve  is  an  elGpse  (See  example  1.  Figure  V3). 

2  Parent  conic  curve  is  a  hyperbola  (See  example  2,  Figure  V3). 

3  Parent  conic  curve  is  a  parabola  (See  example  3,  Figure  V3). 
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104  -  COHIS 


i.k.9  DifCterv  D«t« 

ENTITY  TYPE  NUMBER  :  104 

3.4.10  Pifwter  Data 


Indee 

Name 

Lss 

Oescriotion 

1 

A 

Real 

Conic  Coefficient 

2 

B 

Real 

Conic  Coefficient 

3 

C 

Real 

Conic  Coefficient 

4 

0 

Real 

Conic  Coefficient 

3 

E 

Real 

Conic  Coefficient 

C 

F 

Real 

Conic  Coefficient 

7 

rr 

Real 

ZT  Coordinate  of 
plane  of  definition 

S 

XI 

Real 

Start  Point  Abecisaa 

9 

Y1 

Real 

Start  Point  Ordinate 

10 

X' 

Real 

Terminate  Point 
Abscissa 

11 

Y2 

Real 

Terminate  Point 

Ordinate 

Additional  Pointers  as  required  (see  2.2.4.4.2). 
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APPENDIX  E  -  CONIC  AACS 


APPENDIX  E 
CONIC  ARCS 


Conic  arcs  as  specified  by  the  ICES  standard  are  extremely  sensitive  to  the  data  in 
two  distinct  ways 

(a)  Acoracy 

It  is  numerically  sensitive}  small  changes  in  the  coefficients  can  cause 
large  changes  in  the  locations  of  the  points  satisfying  the  conic  equation. 

(b)  Stability 

The  determination  of  the  conic  type  depends  upon  whether  certain 
invariants  are  positive,  zero  or  negative.  Vorking  in  floating  point 
arithmetic,  a  machine  value  of  0.0  is  unlikely  to  be  encomtered. 
Pvrthermore,  small  changes  in  coefficient  values  can  easily  result  in 
positive  values  when  negative  ones  are  intended  and  conversely. 

It  is  auumed  that  data  is  put  into  a  conic  arc  entity  with  the  intent  of  preserving 
the  geometric  properties  of  the  data  (major  and  minor  semi«axes,  asymptotes, 
directrices,  etc.)  in  addition  to  describing  the  points  on  the  curve. 

If  the  geometric  properties  are  desired,  the  10b  entity  should  be  used  as  described 
below. 

This  method  primarily  add’ssses  the  stability  problem,  though  the  accvacy  of  the 
conic  should  improve  because  the  range  of  coefficient  values  will  decrease.  While 
the  geometric  properties  are  not  explicitly  defined  in  this  representation,  they  can 
be  obtained  from  it  in  a  direct  and  arithmetically  stable  manner. 

If  both  the  sending  and  intended  receiving  system  are  known  to  use  the  A-P  form  of 
the  lOa  entity  (Conic  Arc)  in  their  own  databases  the  preprocessor  may  put  the  data 
into  in  the  unchanged  form.  This  minimizes  the  lou  of  information  caused  by 
tnmeation  and  roundoff  errors  as  no  changes  are  made  to  the  data.  The  stability 
problem  is  presumably  net  of  concern  in  this  ease. 


APPENDIX  E  >  CONIC  ARCS 


Here  is  one  suggested  set  of  values: 

(1)  ElUpse 

A  ;.AX1SY2  B  0 

C  :aAXlSX2  0  :a  0 

E:aO  F;«-A*C 

where  AXISY  and  AXISX  are  the  lengths  ol  the  major  and  miner  semi¬ 
axes  (not  necessarily  in  order). 

(2)  Hyperbola 

A  -  AXISY2  (or  ♦  AX1SY2)  B  0 

C  :a  ♦  AXISX  2  (or  -  AX1SX2,  if  A  0)  0  :>  0 


E  0  F  i«  -A*C. 

where  AXISY  and  AXISX  are  the  lengths  of  the  major  and  miner  semi¬ 
axes  (not  necessarily  in  order). 

(3)  Parabola 

A  ta  0  (or  1  )  B  :a  0 

C  la  1  (or  0,  if  A  a  1)  D  :a  %*DIST 

(or  0,  if  A  a  1) 

E  :a  0  (or  ••OIST,  If  A  a  1)  F  :a  0 

where  OIST  is  the  distance  of  the  vertex  from  the  focus. 


Preprocessor  Conic  Handlint 

The  conic  arc  must  be  put  into  standard  form,  parallel  to  the  X  and/or  Y  axis(axes) 
and  centered  about  the  origin.  An  12b  transformation  matrix  must  be  used  to  move 
the  conic  arc  into  its  desired  position  in  space.  In  this  form  the  coefficients  in  the 
format  that  should  be  0.0  will  be  exactly  so.  In  particular,  for  the  ellipse  and 
hyperbola  B,  0.  and  E  must  be  0.0,  and  for  the  parabola  B  and  F  and  either  A  and  E 
or  C  and  0  must  be  0.0. 

Determination  of  the  conic  type  from  the  equations  becomes  straight  forward  for 
the  postprocessor. 

For  further  mathematical  details,  see  (THOM60). 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentauon  of  proposal  1C  Apr:.!  I?;"? 


sponsoring  authority  ANSI 


'lass  of  Graphical  Item:  GDP 


iDP  Identifier:  parametric  spline  curve 

•escription:  '  ‘  ^ 

A  planar  (two  dimensional)  parametric  spline  curve  is  generated.  The  intended 
realization  of  this  output  primitive  is  equivalent  to  that  intended  for  the 
Parametric  Spline  Curve  Entity  of  ANSI  Y14.26  (IGES  Version  3.0),  with  the 
restriction  that  the  "Z  polynomial"  of  the  IGES  standard  be  zero.  See  the 
attached  sheets  for  more  details. 


idditiooai  Comments:  None 


lustification  for  Inclusion  in  the  Register: 

Parametric  spline  curves  are  needed  to  support  the  requirements  of  engineeri.-.g 
drawing  exchange.  They  are  commonly  found  in  proprietary  graphics  systems. 


lelationsbip  to  Particular  Standards: 

1)  ISC  7542  (jKS)  -  Specifies  a  registered  GC?  as  defined  i.n  5.3. 

2!  ISC  5532  CC-X)  -  Specifies  a  registered  GC?  as  defined  in  5.5,11. 

3)  ISO  8651"  (GKS  Language  Pindings)  -  Specifies  a  registered  GC? . 
(see  attached  sheets). 


"At  present  at  tne  stage  of  draft.  The  status  of  this  relationship  is 
provisional  until  this  standard  nas  been  approved  by  ISC  cou.ncil. 
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1)  COM  Functional  Spacification  (reference  ISO  8632  CGM; 

Part  1 Functional  Description) 

The  parametric  spline  curve  is  a  realization  of  the  Para.T.et  r c 
Spline  Curve  Entity  of  the  IGES  3.0  standard,  restricted  to  the 
two-di.“ens ional  environment  of  the  CGM.  The  attached  extracts  frc.-  - 
the  IGES  Version  3.0  standard  provide  the  functional  specif  icaticr. . 

A  functional  description  of  the  parametric  spline  curve  parameters 
is  : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list(nP)  -  contains  the  "T"  values 

data  record  (D) ;  -  see  the  IGES  attachments  for  definitions 
CTYPE 
H 
N 

AX 

AY 

TPX 

TPY 

Items  for  Data  Record: 

If  VDC  TYPE  integer  was  selected  (Warning;  parametric  splines 
should  not  be  expected  to  work  well  in  this  case) : 

The  following  values  are  in  the  same  order  as  in  the  IGES  standard 
with  the  Z  values  ommitted. 


Integer 

IL 

3  +  9N 

Integer 

IA(1) 

CTYPE 

Integer 

IA(2) 

H 

Integer 

IA(3) 

N 

Integer 

IA(5) 

T(l) 

Integer 

lA (5+N) 

T (N-1) 

Integer 

IA(5+N+1) 

AX(1) 

Integer 

RL 

0 

Integer 

SL 

0 
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112  -  PARAMETRIC  SPLINE  CURVE 


3.*  Pifarn«tric  SoUr>«  Curv  Entity 

(Consult  Appendix  D  for  additional  mathematical  details) 

The  parametric  spline  cxrve  is  a  sequence  of  parametric  polynomial  segments. 
The  CTYPE  value  in  Parameter  1  indicates  the  type  of  curve  as  it  was 
represented  in  the  sending  (pre-processing)  system  before  conversion  to  this 
entity. 

3.t.l  The  N  polynomial  segments  are  delimited  by  the  breakpoints  T(i),  T(2), 
...,T(N*1).  The  coordinates  of  the  points  in  the  i-th  segment  of  the  curve  are 
given  by  the  following  cubic  polynomials  (the  coefficients  Ot  or  C  and  0  will  be 
zero  if  the  polynomials  are  of  degrees  2  or  1,  respectively)! 

j(e)-i4X(/)<»>  jx(/)  •ii'f  card)  ctrd)  v 

rMmAni)*Mro)  •tt-crin 
2(«)«i4Zd)<«>  JZd)  ^4>CZd)  VeAZd)  V 

wban 

rd)<e<r(H>|).l-l^jV 

««e— rd) 

In  order  to  avoid  degeneracy,  for  each  i  at  least  one  of  the  nine  real  coefficients, 
BXU),  eXQ),  OXU),  dYU),  CY(i},  OYQ),  BZU),  CZG),  and  OZQ)  must  be  non-zero. 

3.5.2  If  the  spline  is  planar,  it  must  be  parametrized  in  terms  of  the  X  and  Y 
polynomials  only.  The  Z  polynomial  will  then  be  zero  except  for  each  i,  the  AZG) 
term  which  indicates  the  Z-depth  in  definition  spade. 

3.5.3  The  parameter  H  is  used  as  an  indicator  of  the  smoothness  of  the  arve.  If  HaO, 
the  curve  is  continuous  at  all  breakpoints.  If  Hal,  the  curve  is  continuous  and 
has  slope  continuity  (see  section  (.3  of  PAUX79)  at  all  breakpoints.  If  Ha2,  the 
cirve  is  continuous  and  has  both  slope  and  ctrvature  continuity  at  all  breakpoints 
(see  section  6.3  of  Faux79). 
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If  VDC  TY-PE  real  was  selected: 


Integer  IL 

3 

Integer  IA(1) 

CTYPE 

Integer  IA(2) 

H 

Integer  IA(3) 

N 

Integer  RL 

lON+1 

Real  RA(1) 

T(l) 

Real  RA(N+1) 

T(N+1) 

Real  RA(N+2) 

AX(1) 

Real  RA(N+3) 

BX(1) 

Integer  SL 

0 

Data  Record  Description: 

The  parameters  are  as  defined  in  the  attached  extract  from  the 
IGES  standard. 


2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTRAN-style  paclced  data 
record.  This  is  treated  as  a  string  type  in  each  encoding  and  is 
encoded  according  to  the  rules  for  string  in  that  encoding. 
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112  •  PARAMETRIC  SPLINE  Cun« 


3.1.4  To  enable  determination  oi  the  terminate  point  and  derivatives  without 
computing  the  polynomials,  the  Nth  polynomials  and  their  derivatives  are 
evaluated  at  u  «  T(N«1).  These  data  are  divided  by  appropriate  factorials  and 
stored  following  the  polynomial  coefficients.  For  example,  the  name  TPY3  will 
be  used  to  designate  1/3!  times  the  third  derivative  of  the  Y  polynomial  for  the 
Nth  segment  evaluated  at  uvT(N«l),  the  parameter  value  corresponding  to  the 
terminate  point.  Note  that  these  data  are  redimdant  as  they  are  derived  from 
the  data  defining  the  Nth  polynomial  segment. 


3.1.3  An  example  of  a  parametric  spline  is  shown  in  Figtre  V7.  Additional  examples 
are  shewn  in  Figure  >1. 


3.1.6  Oirectorv  Data 

ENTITY  TYPd  NUMBER  :  112 

3.1.7  Parameter  t3ata 


Index 

Name 

Jm 

Deacrietion 

1 

CTYPE 

Integer 

Spline  Type 
(ULinear 
2>Quadratic 
3«Cubic 

AaWUsotvFowler 
3aMo4fied 
WUsofwPowler 
lag  spline) 

2 

M 

Integer 

Degree  of  coiw 
tinuity  with 
respect  to  arc 
length 

3 

NOIM 

Integer 

2aplanar 

3anon>planar 

4 

N 

Integer 

Number  of  seg¬ 
ments 

3 

T(l) 

Real 

Break  points  of 

e 

e 

piecewise 

e 

3*N 

e 

T(N-l) 

polynomial 
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3  SCGHCNTS 


112  -  PARAMETHIC  SPLIME  CURVE 
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FIGURE  3-7  EXAMPLE  OF  THE  PARAMETRIC  SPLINE  CURVE  ENTITY 


EXAMPLE 


112  -  parametric  SP’-IR 
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FIG.  5-t  EXmiES  OF  PMNCTIIIC  SPLINE  tniVE  ENTIIY 


112  -  PARAMETRIC  SPLINE  CURVE 


Indos 

Namt 

Typo 

Description 

6*N 

AX(1) 

Rtal 

X  coordinate 
polynomial 

7*N 

BX(1) 

l«N 

CX(1) 

OX(l) 

10«N 

AY(1) 

Y  coordinate 

lUN 

BY(l) 

polynomial 

12«N 

CY(1) 

OY(l) 

U«N 

AZ(1) 

Z  coordinate 

13«N 

BZ(l) 

polynomial 

16«N 

CZ(1) 

17*N 

OZ(l) 

Subs«qtj«nt  X,  Y,  Z 
pelynenuaU  cencludng 
with  the  tw«lv« 
ccMffiei«nts  of  th«  Nth 
pelynomiji  scgmtnt. 

• 

(Th«  par«m«t«n  that  follow  compriM  tho  ovaluations  of  tho  polynomials  of  tho  Nth 
sogmont  and  thoir  darivativos  at  tho  paramotor  vaiuo  uaT(N*l)  corrospondlng  to  tho 
torminato  point.  Subsoquontly  thoM  ovaluationa  art  dividod  by  appropriatt  factorials.) 


136 


132 


112  -  paramstric  spline  clsve 


TPXO 

Real 

X  value 

TPXl 

X  first  derivative 

TPX2 

X  second  derivative/2! 

tPX3 

X  third  derivative/ 3! 

TPYO 

TPYl 

TPY2 

TPY3 

Y  value 

TP20 

Z  value 

TP21 

TP22 

TP23 

Additional  Pointon  «s  roquirod  (sot  2.2.ft.%.2) 

Software  to  convert  between  parametric  spline  curves  or  surfaces  and  the  corresponding 
rational  &-spUne  cvrves  or  surfaces  is  available  from  the  ICES  office  at  the  National 
Bureau  of  Standards.  Materials  provided  include  a  magnetic  tape  of  Pascal  source  code,  a 
listing  of  the  cede,  and  accompanying  documentation. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  10  April  1987 


sponsoring  authority  ANS I 


Class  of  Graphical  Item:  GDP 


GDP  Identifier:  rational  B-spline  curve 


escnption: 

A  planar  (two  dimensional)  rational  B-spline  curve  is  drawn.  The  intended 
realization  of  this  output  primitive  is  equivalent  to  that  intended  for  the 
Rational  B-Spline  Curve  Entity  of  ANSI  Y14.26  (IGES  Version  3.0),  with  the 
restriction  that  the  "Z  polynomial"  of  the  IGES  standard  be  zero.  See  the 
attached  sheets  for  more  details. 


Additional  Comments:  None 


ustification  for  Inclusion  in  the  Register: 

Rational  B-spline  curves  are  needed  to  support  the  requirements  of  engineering 
drawing  exchange.  They  are  commonly  found  in  proprietary  graphics  systems. 


elationsbip  to  Particular  Standards: 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  GDP  as  defined  in  5.3. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  GDP  as  defined  in  5.6.10. 

3)  ISO  8651^  (GKS  Language  Bindings)  -  Specifies  a  registered  GDP. 

(see  attached  sheets) . 


"At  present  at  the  stage  of  draft.  The  status  of  this  relationship  is 
provisional  until  this  standard  has  been  approved  by  ISO  council. 
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1)  CGM  Functional  Spaeiflcation  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description)  - 

The  rational  B-splina  curve  is  a  realization  of  the  rational 
B-spline  curve  Entity  of  the  IGES  3.0  standard.  The  attached 
extracts  from  the  IGES  Version  3.0  standard  provide  the  functional 
specification . 

A  functional  description  of  the  rational  B-spline  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

point  list(nP)  -  contains  the  control  points 

data  record  (D) :  -  see  the  IGES  attachments  for  definitions 

K 

M 

PROP  2 
PROP  3 
PROP  4 
T 
W 

NORM 

Note:  The  PROPl  value  is  not  included  since  it  must  be  1. 

Items  for  Data  Record: 


The  following  values  are  in  the  same  order  as  in  the  IGES  standard. 


Integer  IL 
Integer  IA(1) 
Integer  IA{2) 
Integer  IA(3) 
Integer  IA(4) 
Integer  IA(5) 
Integer  RL 
Real  RA(1) 


5 

K 

M 

PROP  2 
PROP  3 
PROP  4 

see  IGES  extract 
T(-M) 


Real  RA(1+A)  W(0) 

Real  RA{2+A+K)  XNORM 

Real  RA{3+A+K)  YNORM 

Integer  SL  0 


Data  Record  Description: 


The  parameters  are  as  defined  in  the  attached  extract  from  the 
IGES  standard. 
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2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTRAN-style  packed  data 
record.  This  is  treated  as  a  string  type  in  each  encoding  and  is 
encoded  according  to  the  rules  for  string  in  that  encoding. 
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126  •  HATIOMAL  B  SPLINE  CL'BVE 


3.14  R«ticn»l  ft»SoUn«  Curv  Entity 

Th«  rfttion«I  ft>tplin«  curv*  may  rtpr«9«nt  «n«iytic  curws  of  (onoral  intorut. 
This  inlermation  is  important  to  both  th«  sanding  and  rocaiving  systams.  Tha 
Aractory  antry  form  numbar  paramatar  is  previdad  to  eomm«mieata  this 
information.  It  should  ba  amphasUad  that  uaa  of  this  eurva  form  should  ba 
rastrictad  to  communications  batwaan  systams  oparating  diractly  on  rational  ft* 
spUna  curvas  and  not  usad  as  a  raplacamant  for  tha  analytic  forms  for 
oommudeation.  Par  a  brial  daseription  of  a  rational  ft*tplina  orvas*  saa  Saction 
A  of  Appandlx  0. 

IS  tha  rational  ft-splina  eurva  raprasants  a  prafarrad  oxva  typa,  tha  form  numbar 
corrasponds  to  tha  most  prafarrad  typa.  Tha  praforanea  ordar  is  from  1  through 
3  foUowad  by  0.  Par  axampla.  If  tha  or va  is  a  dreia  or  circular  are,  tha  form 
numbar  is  sat  to  2.  IS  tha  evrva  it  an  alilpaa  with  lataqual  major  and  minor  axis 
langtha,  tha  form  manbar  is  sat  to  3.  If  tha  cwa  is  not  ona  of  tha  prafarrad 
typas,  tha  form  numbar  is  sat  to  0. 

If  tha  orva  lias  antiraly  sdthin  a  unipua  plana,  tha  planar  flag  (PROPl)  is  sat  to 
1,  otharwisa  it  is  sat  to  0.  IS  it  is  sat  to  1,  tha  plana  normal  (paramatars 
IS^A^AK  through  li^A«AK)  contain  a  tmlt  vactor  normal  to  tha  plana  containing 
tha  cirva.  Thasa  fialds  axist  but  ara  ignorad  if  tha  cunm  is  non-ptanar. 
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126  -  RATIONAL  B  SPLINE  CURVE 


It  th«  tndlng  points  on  tho  ojrv*  art  idtntical,  PROP2  is  itt  to  1. 

11  they  art  not  tqual*  PROP2  is  stt  to  0. 

If  tht  curvt  is  rational  (dots  not  havt  all  wtights  tqual).  PROPS  u  »tt  to  0.  It 
all  wtights  art  tqual  te'tach  othtr,  tht  curvt  is  polynomial  and  PROPS  is  stt  to 
1.  Tht  cirvt  is  polynomial  sinct  in  this  cast  all  ttights  canctl  and  the 
dtnominator  sums  to  ont  (stt  Appendix  Od)« 

If  tht  orvt  is  periodic  with  respect  to  its  parametric  variablt,  set  PROP#  to  1, 
otherwise  stt  PROP%  to  0. 


3.16.1  Directory  Dau 

ENTITY  TYPE  NUMBER*  126 
Form  Mtanint 

0  Form  of  cirvt  mutt  be  determined  from  the  rational  B-spline 

parameters. 

1  Line 

2  Circular  arc 

3  Elliptical  are 

4  Parabolic  arc 

3  Hyperbolic  are 

3.16.2  Parameter  Data 


Index 

Name 

Type 

Description 

1 

K 

Intefar 

Upper  index  of 
sum.  See 
Appendix  D 

2 

M 

Integer 

Degree  of  basis 

fisicuons 

3 

PROPl 

Integer 

sO  >  non^planar 
sl  •  planar 

4 

PROP2 

Integer 

xO  >  open  ctrve 
■  1  •  closed 
a»ve 

3 

PROPS 

Integer 

xO  -  rational 

X 1  •  polynomial 

6 

PROP4 

Integer 

xO  •  no(v 
periodic 

«1  -  periodic 


Let  N«K.M«1  and  let  AaN*2M 
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126  -  RATIONAL  S  SPLINE  H- 


7 

Tt-M) 

• 

Real 

Knot  Sequence 

• 

• 

7*A 

• 

• 

T(N*M) 

e 

W(0) 

• 

Real 

Weights 

• 

e 

S«A«K 

e 

• 

W(K) 

9«.A«'K 

XO 

Real 

Control  Points 

10«A«K 

YO 

1UA«K 

e 

ZO 

• 

e 

e 

• 

e 

XK 

10-»A*4K 

YK 

1UA^9K 

ZK 

12«A«9K 

V(0) 

Real 

Starting  para¬ 
meter  value 

13*A-»9K 

V(l) 

Real 

Ending  para¬ 
meter  value 

2««A*9K 

XNORM 

Real 

Unit  Normal  Qf 
curve  is  planar) 

13«A*«K 

YNORM 

16-rA4>«K 

ZNORM 

Additional  Pointers  as  required  (see  2.2.^.k.2). 

Software  to  convert  between  parametric  spline  curves  or  surfaces  and  the  corresponding 
rational  &>tpUne  curves  or  surfaces  is  available  from  the  ICES  office  at  the  National 
Bureau  of  Standards.  Materials  provided  include  a  mapietic  tape  of  Pascal  source  code,  a 
listing  of  the  code,  and  accompanying  documentation. 
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APPENDIX  D  -  SPLINE  HEPSESENTATICNS 


D*  RATIONAL  ft-SPLINE  CURVES 

0 

Th«  comnMnts  in  this  section  pertain  primarily  to  section  3.16. 

A  rational  B-spUne  ctrve  is  expressed  parametrically  in  the  form 

K 

2  waipofcjft) 

j-o 

C(t)«  ■ 

K 

2  vobiW 

leO 

where  the  notation  is  interpreted  as  follows. 

The  W(i)  are  the  weights  (norvzero  real  numbers). 

The  P(i)  are  the  control  points  (points  in  r\ 

4  72 


141 


APPENSIX  3  -  SPLINE  aEPSES-NTATIlNS 

The  b.  are  the  B-soline  basis  f  jnctions.  These  are  defined  as  soon  as  their 
degree,  M,  and  underlying  knot  sequence.  T,  are  ipeafied. 

This  is  done  as  follows: 

Let  N  »  K  -  M  ♦  1.  Then,  the  kr'ot  sequence  consists  of  the  non-decreasing 
set  of  real  numbers;  T(-M),  T(0),  T{N)»  -t  T(N*M) 

The  ctjfve  itself  is  parametrized  for  V(0)^t^V(l)  where 
T(0)4V(0)^V(1)4T(N>. 

The  ft>spUne  basis  functions  b.^  are  each  noivnegative  piecewise  polynomials 
of  degree  M.  The  function  b.  is  supported  by  the  interval  IHi-A/).  ni*l)]. 
Between  any  two  adjacent  knot  values  T{j),  T(j*l)  the  fusction  can  be 
expressed  as  a  single  polynomial  of  tegree  M* 

Pof  iny  parameter  value  t  between  T(0)  and  T(N)  the  basis  functiona  satisfy 
the  identity 

K 

II  the  weights  are  all  positive,  the  curve  G(t)  is  contained  within  the  convex 
hull  of  its  control  points. 

There  are  a  number  of  ways  to  precisely  define  the  B-spline  basts  functions. 

A  recursive  approach  proceeds  as  follows. 

Let  Nit  It.  ,.~,t.  ,)  denote  the  B-spline  basis  function  of  degree  m 
I  i-rn  i*  l  . 

supported  by  the  interval 

With  this  notation,  the  degree  0  fvmctions  are  simply  characteristic  functions 
of  a  half-open  interval. 

I  ,  1  if  «<'<* 

N(i  I  «,*)  *  Q  oiberwias 
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append: 


0  -  SPLINE  REPRESENTATIONS 


The  degree  k  functions  are  defined  in  terms  of  those  of  degree  k-1. 
NU  |i«..  ••.<*)• 

(i-s«)V<>  |«o. - ««-i)  ^  (s,~t>y(f  Ui . U) 

h-i  -H  ^  -  '1 


Since  some  of  the  denominators  will  be  0  in  the  case  of  multiple  Imots,  the 
convention  0/0  a  0  is  adopted  in  the  above  definition. 

Rational  Bezier  curves  (and  surfaces)  can  be  expressed  exactly  as  rational  ^ 
spline  curves  (and  surfaces).  (BLOMS2). 

Software  to  convert  between  parametric  spline  curves  or  surfaces  and  the 
corresponding  rational  B>spline  curves  or  sirfaccs  is  available  from  tfte  ICES 
office  at  the  i<lational  Bureau  of  Standards.  Materials  provided  include  a 
magnetic  tape  of  Pascal  source  code,  a  listing  of  the  code,  and  accompanying 
documentation. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 
date  of  presenution  of  proposal  jg  ^937 


sponsoring  authority  ANSI 


kClass  of  Graphical  Item:  ESCAPE 


Specific  Escape  Function  Identifier:  Set  Conic  Arc  Trannfocination  Matrix 


Description: 

This  escape  function  sets  a  value  of  the  transformation  matrix  needed  to 
describe  how  a  conic  arc  described  by  the  conic  arc  GDP  is  moved  from  "defini¬ 
tion  space"  to  world  coordinates  (called  "model  space"  in  the  IGES  standard.) 
It  is  modelled  on  the  Transformation  Matrix  Entity  of  the  ANSI  Y14.26  (IGES 
version  3.0)  specification.  See  attached  sheets  for  additional  details. 


Additional  Comments: 

None 


I _ 

JusUncation  for  Inclusion  in  the  Register: 

Iconic  arcs  are  needed  to  support  the  requirements  of  engineering  drawing  exchange. 
They  are  commonly  found  in  proprietary  graphics  systems.  Due  to  various  numerical 
problems,  such  curves  are  beat  specified  in  a  "definition  space"  and  then  trans¬ 
formed  to  t.heir  final  location  by  applying  a  transformation  matrix.  This  escape 
function  is  needed  to  supply  values  for  the  required  "modelling"  or  transformation 
matrix. 


Relatioosbip  to  Particular  Standards: 

1)  ISO  8632  (C(3M)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 


2)  See  attached  sheets. 


1)  CGM  Functional  Spacification  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

Sat  Conic  Arc  Transformation  Matrix  is  a  realization  of  the 
Transformation  Matrix  Entity  of  the  IGES  3.0  standard,  restricted 
to  the  two-dimensional  environment  of  the  CGM.  This  matrix  is  a 
component  of  the  graphics  state  and  determines  how  subsequent  conic 
arc  output  primitives  are  transformed  from  definition  space  to 
virtual  device  coordinates.  The  attached  extracts  from  the  IGES 
Version  3.0  standard  provide  the  functional  specification. 

A  functional  description  of  the  Set  Conic  Arc  Transformation 
Matrix  escape  parameters  is: 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) :  -  see  the  IGES  attachments  for  definitions 
^11 
Ri2 
R21 
R22 

Items  for  Data  Record; 

If  VDC  TYPE  integer  was  selected  (Warning:  conic  arcs  should 
not  be  expected  to  vork  well  in  this  case) ; 


Integer  IL  6 

Integer  IA(1)  Rj_j^ 

Integer  IA(2)  R22 

Integer  IA(3)  R21 

Integer  IA(4)  R22 

Integer  IA(5)  T]_ 

Integer  IA(6)  T2 

Integer  RL  0 

Integer  SL  0 

If  VDC  TYPE  real  was  selected: 

Integer  IL  0 

Integer  RL  6 

Real  RA(1)  R^l 

Real  RA(2)  R^2 

Real  RA ( 3 )  ^21 

Real  RA{4)  R22 

Real  RA(5)  Tj^ 

Real  RA(6)  T2 

Integer  SL  0 
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Data  Record  Description: 

The  parameters  are  as  defined  in  the  attached  extract  from  the 
ANSI  Y14.26  (IGES  versif'n  3.0)  standard. 

2)  CGM  Encodings  (reference  ISO  8632  COM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTPAN-st  yle  pac.'ced  data 
record.  This  is  treated  as  a  string  type  in  each  encoding  and  is 
encodea  according  to  the  rules  for  string  in  that  encoding. 
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12it  .  TRANSFORMATION  MATRIX 


3.1<*  Translornwioo  Matrix  Entity 

Tb«  Transformation  Matrix  antity  transforms  thre«-row  column  vectors  by 
moans  of  a  matrix  multiplication  and  then  a  vector  addition.  The  notation  for 
this  transformation  is 


’Rll  Ri2Ri3‘ 

‘xinput' 

'tr 

'XOUTPUT* 

*21  *22  *23 

YINPUT 

♦ 

T2 

a 

YOUTPUT 

.*31  *32  *33. 

2INPUT 

k  d 

.T3, 

.20UTPUT. 

Here,  col  ^XINPUT,  YINPUT,  ZINPUxj  (i.e.,  the  column  vector)  is  the  vector  being 
transformed,  and  col  ^XOUTPUT,  YOUTPUT,  ZOUTPUlj  is  the  column  vector  resulting 
from  this  transformation,  R  a  is  a  3  row  by  3  column  matrix  el  real  numbers, 
and  Taeol  ^Tl,T2,T3j  is  a  three-row  column  vector  of  real  numbers,  Titus,  12  real 
numbers  are  required  for  a  Transformation  Matrix  entity.  This  entity  can  be 
considered  to  be  an  "operator*  entity  in  that  it  starts  with  the  input  vector, 
operates  on  it  as  described  above,  and  proves  the  output  vector. 

3,1A.1  Frequently,  the  input  vector  lists  the  coordinates  of  some  point  in  one  coordinate 
system,  and  the  output  vector  lists  the  coordinates  of  that  same  point  in  a 
second  coordinate  system.  The  matrix  R  and  the  translation  vector  T  then 
express  a  general  relationship  between  the  two  coordinate  systems.  By 
eonsiderating  special  input  vectors  such  as  cel^l,0,l^,  col[o,l,oj,  and  cel[o,0,lj 
and  computing  the  corresponding  output  results,  a  geometric  appreciation  of  the 
spatial  relationship  between  the  two  coordinate  system  can  be  gained. 

For  example,  for 


■  0  0  r 

’o' 

R  « 

0  1  0 

T  . 

0 

,-l  0  0, 

.0. 
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3.U.2 


12«  -  THANSFCHMATICN  matrix 


the  sp«tt«i  relationship  of  the  input  and  output  cordinate  systems  is  the 
following: 


zoumiT 


Ail  eeerdinato  systems  art  aaaunMd  to  be  ortfwgonai,  cartesian,  and  right«handad 
veiless  specif  Icaily  noted  otherwise. 


Poliowing  are  three  specific  areas  where  the  Transformation  Matrix  entity  is 
used  to  transform  coordinates  between  coordinate  systems.  Each  example  area 
illustrates  a  speeifie  choice  of  input  and  output  coordinate  system.  Other 
choices  of  coordinate  systems  may  be  appropriate  in  ether  application  areas. 

The  uwal  situation  for  this  type  of  use  of  the  Transformation  Matrix  entity  is 
when  the  input  vector  refers  to  the  definition  space  ceerdirtate  system  for  a 
certain  entity,  and  the  output  vector  refers  to  the  model  space  coordinate 
system.  (See  Sect.  3.1.1)  In  this  case,  the  matrix  R  is  referred  to  as  the  defining 
matrix,  and  the  Transformation  Matrix  entity  defining  R  and  T  is  pointed  to  in 
field  seven  (transformation  matrix  field)  of  the  directory  entry  of  the  entity. 
(See  Sect.  2.2.A.3.7)  In  this  use  of  the  Transformation  Matrix  entity,  the  matrix 
R  is  subject  to  the  restrictions  given  in  Form  0  and  Form  I  below. 
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124  -  TRANSFORMATION  MATRIX 


A  second  situation  is  the  case  when  the  input  vector  refers  to  the  model  space 
coordinate  system  and  the  output  vector  refers  to  a  viewing  coordinate  system. 
In  this  case,  the  matrix  R  is  referred  to  as  a  view  matrix,  and  is  subject  to  the 
restrictions  given  in  Form  0  below.  Note  that  when  a  planar  entity  is  viewed  at 
true  length  (i.e.,  the  viewing  plane  is  parallel  to  the  plane  containing  the  entity) 
then  the  roution  matrit  pointed  to  by  OC  Field  7  of  the  planar  entity  will  be  the 
inverse  (smatrix  transpose)  of  the  matrix  pointed  to  by  OE  Field  7  of  the  View 
entity.  (See  Sect.  4.3.11) 

A  third  situation  involves  finite  element  modeling  applications.  Here,  it  may  be 
the  case  that  an  input  coordinate  system  is  related  to  an  output  coordinate 
system  by  a  particular  R  and  T,  and,  in  turn,  the  output  coordinate  system  is 
then  taken  as  an  input  coordinate  system  lor  a  second  R  and  T  combination,  and 
so  on.  These  coordinate  systems  are  frequently  called  local  coordinate  systems. 
Model  space  is  freqoently  called  the  reference  system.  For  example,  the 
location  of  a  finite  element  node  may  be  given  in  one  local  coortfnate  system, 
whld)  may  serve  as  the  input  coordinate  system  for  a  second  local  coordinate 
system,  which  in  turn  serves  as  the  input  coordinate  system  for  the  model  space 
coordinate  system  which  is  the  reference  system.  Allowable  forms  of  the  matrix 
R  for  these  applications  are  detailed  in  Forms  10,  11,  and  12  below. 

3.14.3  Whenever  coordinate  systems  are  related  successively  to  each  other  as  dsecribed 
above,  a  basic  result  is  that  the  combined  effect  of  the  indvidual  coordinate 
system  changes  can  be  expres^  in  terms  of  a  single  matrix  R  and  a  single 
translation  vector  T.  For  example,  if  the  coordinate  system  change  involving  the 
matrix  R2  and  the  translation  vector  T2  is  to  be  applied  following  the  coordinate 
system  change  involving  the  matrix  R1  and  the  translation  vector  Tl,  then  the 
matrix  R  and  the  translation  vector  T  expressing  the  combined  changes  are 
R.<R2)  (Rl)  and  T  .  (R2)  (Tl)  ♦  T2. 

Here,  (R2)  (Rl)  denotes  matrix  multiplication  of  3x3  matrices,  where 
multiplication  order  is  important.  The  matrix  R  and  the  translation  vector  T  are 
computed  similarly  whenever  more  than  two  coorttnate  system  changes  arc  to  be 
applied  successively. 
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12U  -  TRANSFORMATION  MATRIX 


Successive  coordinate  system  cManges  are  specilied  by  allowing  a  Transtormation 
Matrix  entity  to  reference  another  Transformation  Matrix  entity  through  Field  7 
of  the  Directory  Entry.  In  the  example  above,  the  Transformation  Matrix  entity 
containing  R1  and  T1  would  contain  in  its  Directory  Entry  Field  7  a  pointer  to 
the  Transformation  Matrix  entity  containing  R2  and  T2.  The  general  rule  is  that 
Transformation  Matrix  entities  applied  earlier  in  a  sueeassion  will  reference 
Transformation  Matrix  entities  applied  later.  Note  that  the  matrix  product 
(R2)  (Rl)  in  the  example  above  dees  net  appear  explicitly  in  the  data,  but,  if 
needed,  must  be  computed  according  to  the  usual  rules  of  matrix  multiplication. 

A  second  example  of  coordinate  systems  being  related  sueeaaaively  (or 
"concatenatetf*,  or  "stacKetf*),  in  addition  to  the  finite  element  example 
mentioned  above,  involves  one  manner  of  locating,  into  model  space  a  conic  arc 
that  is  ‘  >  standard  position  in  definition  space.  In  this  case,  Rl  and  T1  move  the 
conic  are  from  its  standard  position  to  an  arbitrary  location  in  any  plane  in 
definition  space  satisfying  ZTaconstant.  (Therefore,  RI33BIU), 
Rl3|aRl32aRli3a  Ri23a0.0.  T1  can  be  an  arbitrary  translation  vector.)  R2  and 
T2  then  position  the  relocated  conic  are  into  model  space.  (R2  can  be  an 
arbitrary  defining  matrix  and  T2  can  be  an  arbitrary  translation  vector.)  Note 
that  for  Rl  and  Tl,  both  the  input  vector  and  the  output  vector  refer  to  the 
same  coordinate  system,  namely,  the  definition  space  for  the  conic  are. 

3.1A.a  A  3x3  matrix  R  is  called  orthogonal  provided  its  transpose,  R*,  about  the  main 
diagonal  yields  a  matrix  inverse  for  R.  The  columns  of  an  orthogonal  matrix 
considered  as  vectors  form  an  orthogonal  collection  of  wtit  vectors.  As  (R^^aR, 
the  transpose  of  an  orthogonal  matrix  is  again  an  orthogonal  matrix.  The 
determinant  of  an  orthogonal  matrix  is  equal  to  either  plus  one  or  minus  one.  In 
the  event  R  is  an  orthogonal  matrix  with  determinant  equal  to  positive  one,  R 
can  be  expressed  as  a  roution  about  an  axis  passing  through  the  origin.  In  this 
event,  R  is  referred  to  as  a  rotation  matrix.  In  the  event  R  is  an  orthogonal 
matrix  with  determinant  equal  to  negative  one,  R  can  be  expressed  as  a  rotation 
about  an  axis  passing  through  the  origin  followed  by  a  reflection  about  a  plane 
passing  through  the  origin  perpendicular  to  the  axis  of  rotation. 
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12«  -  TRANSFORMATIOM  MATRIX 


3.U.3  Allowabl*  Form  Numbors.  The  defining  matrix  of  *n  entity  must  use  either 
Form  zero  or  Form  one.  A  defining  matrix  associated  with  a  view  entity  must 
use  Form  zero. 

Form  Oi  (default)  R  is  an  orthogonal  matrix  with  determinant  equal  to  positive 
one.  T  is  arbitrary.  The  columns  of  R  taken  in  order  form  a  right-handed  triple 
in  the  output  coordinate  system. 

Form  it  R  is  an  orthogonal  matrix  with  determinant  equal  to  negative  one.  T  is 
arbitrary.  The  columns  of  R  taken  in  order  form  a  left-handed  triple  in  the 
output  coordinate  system. 

3.lA.g'  Forms  10,  lif  12.  These  form  numbers  i.idicate  special  matrices  used  in 
conitmetion  with  thn  node  entity  (type  number  134). 

Form  IQt  This  form  number  conveys  special  information  when  used  in 
conjtmction  with  the  Node  entity  (type  number  134)  in  Finite  Element 
Applications. 

Refer  to  Fig.  3-17(a)  for  notation.  The  matrix  R  and  the  vector  T  are 
used  to  transform  coordinate  data  from  the  ul,u2«u3  coordinate 
system  to  the  x,y,z  local  system. 

The  ui,u2.u3  coordinate  system  has  its  origin  at  an  arbitrary  fixed 
point  col  XOFFSET,  YOFFSET,  ZOFFSET  in  the  x,y,z  coordinate 
system  and  is  assumed  to  be  displaced  parallel  to  that  reference 
coordinate  system.  Thus* 


’l  0  o' 

‘  xoffset' 

R  a 

0  1  0 

,  T  a 

YOFFSET 

0  0  1 

•  d 

.ZOFFSET. 
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z 


Figure  3-17  Displacement  Components 
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12«l  -  TRAHSfORMATtOM  MATRIX 


so  that 


‘l  oo' 

m  « 

ul 

■  XOFFSET' 

'xlocal' 

0  1  0 

u2 

♦ 

YOFFSET 

S 

YLOCAL 

.0  0  1, 

.u3, 

.ZOFFSET, 

.ZLOCAL, 

Net*  that  th*  orientation  of  tho  two  coordinat*  systonu  can  bo 
d«*crib*d  by  saying  that  tho  ul,u2«u3  ceordinato  system  is  tho 
system  obtained  by  imposing  orthogonal  curvilinear  coordinates 
onto  :a*  x,y,z  spec*  and  then  constructing  utit  tangent  vectors  to 
th*  three  curvilinetf  coordinate  curves  at  th*  given  fixed  point  to 
serve  as  basis  vectors.  In  this  special  case  of  parallel 
displacement,  th*  curvilinear  coordinates  imposed  are  identical  to 
th*  existing  x,y,z  coordinates. 

Form  lit  This  form  number  conveys  special  information  when  used  in 
coniiaiction  with  th*  Nod*  entity  (type  number  13 A)  in  Finite 
Element  applications. 

Refer  rs  Figure  3*  17(b)  for  notation.  Th*  matrix  R  and  th*  vector 
T  are  used  to  transform  coordinate  data  from  th*  ul,  u2,  u3 
coordinate  system  to  th*  s,y,z  local  system. 

Th*  ul,  u2,  u3  coordinate  system  has  its  origin  at  an  arbitrary  fixed 
point 


XOFFSET  .  To  cos  Qo  0 

YOFFSET  «  To  sin  Oo  0  Oq  340® 

ZOFFSET  .  Zo  -oo<2o  <  •« 

for  r^aO,  take  OaO^ 

in  th*  x,y,z  coordinate  system.  Th*  ul,u2,u3  system  is  the  system 
obtained  by  imposing  orthogonal  cvrvUinear  coordinates  onto  th* 
x,y,z  space  which  are  th*  cylindrical  coordinates  (r,e,z)  with 

X  a  r  cos  0 
y  a  r  sin  9 
*  «  *. 

164 


154 


12U  -  transformation  matrix 

and  then  constructing  vnit  tangent  vectors  to  the  three  curvilinear 
coordinate  curves  at  the  given  fixed  point  to  serve  as  basis  vectors. 

Thus,  the  relationship  between  the  ul,  u2,  u3  and  the  x,y,2  local 
coordinate  system  is  given  by 


‘cos8o  •sin8o 

m 

0 

m  m 

ul 

'  XOFFSET ' 

'XLOCAL* 

sin8o  cos8o 

0 

u2 

♦ 

YOFFSET 

S 

YLOCAL 

.  0  0 

1, 

.ZOFFSET, 

.ZLOCAL, 

Form  12:  This  form  number  conveys  special  information  whan  used  in 

conjtatction  with  the  Node  entity  (type  number  13A)  in  Finite 
Element  applications. 

Refer  to  Fig.  )>17(c)  for  notation.  The  matrix  R  and  the  vector  T 
are  used  to  transform  coordinate  data  from  the  ul,  u2,  u3 
coordinate  system  to  the  x,y,z  local  system. 

The  ul,  u2,  u3  coordinate  system  has  its  origin  at  an  arbitrary  fixed 
point 

XOFFSET  •  roSin  Oq  sin  Iq 
YOFFSET  •  r^sin  Oq  oos  Io 
ZOFFSET  «  r^cos  8, 

for  r^  »  0,  take  8,  »  »  0® 

for  8o  «  0®  or  180®,  take  Iq  s  0® 

in  the  x,y,2  coordinate  system.  The  ul,  u2,  u3  system  is  the  system 
obtained  by  imposing  orthogonal  curvilinear  coordinates  onto  the 
x,y,z  space  which  are  the  spherical  coordinates  (r,  8,  I)  with 

X  a  r  sin  8  cos  I 
Y  a  r  sin  8  sin  0 
Z  a  r  cos  8 
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12'»  -  TRANSFORMATION  MATRIX 

«nd  Then  constructing  unit  tangent  vectors  to  the  three  curvilinear 
coordinate  curves  at  the  given  fixed  point  to  serve  as  basis  vectors. 


Thus,  the  relationship  between  the  ul,  u2,  u3  and  the  x,y,2  local 
coordinate  systems  is  given  by 


sinOo  cmIq 

ces0e 

>sinto 

•  m 

ul 

XOFFSET 

•  ^ 

XLOCAL 

sinOe  sinflo 

cosOo  sinflo 

cosio 

u2 

♦ 

YOFFStT 

a 

YLOCAL 

COSAq 

-sin4o 

0 

u3 

m  m 

ZOFFSET 

m  « 

ZLOCAL 

Soe,  Kaplan,  (KAPL32)  or  Hildebrand,  (HlLOTg)  for  a  diaciasion  of  orthogonal 
curvilinear  coordinate  systems. 


3.l%.2 

1 

1 

ENTITY  TYPE  NUMBER:  12« 

3.1A.S 

Parameter  Data 

Index 

Name 

IZEi 

OescriDtien 

1 

Rll 

Real 

Top  Row 

2 

R12 

Real 

3 

R13 

Real 

a 

Tl 

Real 

3 

R21 

Real 

Second  Row 

S 

R22 

Real 

7 

R23 

Real 

t 

T2 

Real 

9 

R31 

Real 

Third  Row 

10 

R32 

Real 

11 

R33 

Real 

12 

T3 

Real 

Additional  Pointers  as  required  (see  2.2.A.A.2). 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  jq  1937 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  ESCAPE 


Specific  Escape  Function  Identifier:  Sec  Dash 


Description: 

This  escape  function  sets  a  value  for  the  user-specified  dash  pattern  (registered) 
linetype . -This  pattern  is  used  during  subsequent  interpretation  of  graphical 
primitives  that  use  linetype  attributes.  See  attached  sheets  for  additional 
details . 


Additional  Comments: 

The  line  type  capability  proposed  here  is  adapted  from  those  in  Che  PostScript 
language  developed  by  Adobe  Systems  Incorporated. 


Justification  for  Inclusion  in  the  Register: 

The  Set  Dash  function  is  needed  to  support  the  user-specified  dash  pattern 
linetype.  This  linetype  is  needed  to  support  the  requirements  of  office  docur.er 
exchange  and  publishing.  Similiar  capabilities  are  commonly  found  in  widely 
available  proprietary  graphics  systems. 


Relationship  to  Particular  Standards: 

1)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 


2)  See  attached  sheets. 
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1)  CGM  Functional  Spaciflcatlon  (reference  ISO  8632  CGM; 

Part  1:  Functional  Description) 

Sat  Dash  sets  a  dash  pattern  state  value  in  the  graphics  state, 
controlling  the  dash  pattern  used  during  subsequent  interpretation 
of  graphics  primitives  that  are  drawn  with  the  registered  linetype 
value  of  "user-specified  dash  pattern"  (linetype  TBD)  .  If  the  array 
of  dash  pattern  lengths  is  empty  (i.e,  the  number  cf  lengths  is 
zero)  ,  the  linetype  is  equivalent  to  solid.  If  array  of  dash 
pattern  lengths  is  not  empty,  the  affected  primitives  are  drawn 
with  dashed  lines  whose  pattern  is  given  by  the  elements  of  the 
array,  which  must  be  non-negative  numbers  and  not  all  zero. 

The  elements  of  the  array  of  dash  pattern  lengths  are  interpreted 
in  sequence  as  distances  in  VDC  units  along  the  path  of  the 
primitive.  These  distances  alternately  specify  the  length  of  a  gap 
between  dashes.  The  contents  of  the  array  are  used  cyclically.  When 
the  end  of  the  array  is  reached,  the  pattern  starts  over  at  the 
beginning. 

Dashed  lines  wrap  around  curves  and  corners  just  as  solid  lines  do. 
The  ends  of  each  dash  are  treated  with  current  line  cap,  corners 
within  a  dash  are  treated  with  current  line  join.  No  measures  are 
required  to  coordinate  the  dash  pattern  with  features  of  an  output 
primit ive . 

The  of/set  value,  in  VDC  units,  may  be  thought  of  as  the  "phase"  or 
the  dash  pattern  relative  to  the  start  of  the  path.  It  is 
interpreted  as  a  distance  into  the  dash  pattern  at  which  the 
pattern  should  be  started.  Before  beginning  output  of  the  dash 
pattern,  the  elements  of  the  array  of  dash  pattern  lengths  are 
cycled  through,  and  the  distances  of  alternating  dashes  and  gaps 
added  up,  but  without  generating  any  output.  When  the  offset 
distance  into  dash  pattern  has  been  reached,  the  primitive  is  drawn 
(from  its  beginning)  using  the  dash  pattern  from  the  point  that  has 
been  reached. 

When  continuity  is  set  to  restart,  each  portion  of  a  primitive 
(e.g.  each  line  segment  within  a  polyline)  is  treated 
independently;  i.e.  the  dash  pattern  is  restarted  (and  offset 
applied)  at  the  beginning  of  each  portion.  When  continuity  is  set 
to  continuous,  the  dash  pattern  is  not  restarted  in  going  from  one 
portion  of  a  primitive  to  the  next. 

A  functional  description  of  the  Set  Dash  escape  parameters  is: 
Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D) : 
offset  (VDC) 

continuity  (one  of:  restart,  continuous)  (E) 
number  of  lengths  (I) 

(nVDC) 

dash  pattern  lengths  array 
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Items  for  Data  Record: 


If  VDC  TYPE  integer  was  selected: 


Integer  IL 

3  +  number  of  lengths 

Integer  IA(1) 

offset 

Integer  IA(2) 

continuity 

Integer  IA(3) 

number  of  lengths 

Integer  IA(4) 

first  length 

Integer  IA(5) 

second  length 

Integer  IA(2+number 

of  lengths)  last  length 

Integer  RL 

0 

Integer  SL 

0 

If  VDC  TYPE  real  was  selected: 

Integer  IL 

2 

Integer  IA(1) 

number  of  lengths 

Integer  IA(2) 

continuity 

Integer  RL 

1  +  number  of  lengths 

Real  RA(1) 

offset 

Real  RA(2) 

first  length 

Real  RA(3) 

second  length 

Real  RA(l+number  of 

lengths)  last  length 

Integer  SL 

0 

Data  Record  Description: 

The  parameters  define 

the  offset,  continuity,  number  of  dash 

pattern  lengths,  and  the  dash  pattern  lengths.  I 

2)  CGM  Encodings  (reference  ISO  8632  COM;  Parts  2,3,4) 


All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTRAN-style  packed  data 
record.  This  is  treated  as  a  string  type  in  each  encoding  and  is 
encoded  according  to  the  rules  for  string  in  that  encoding. 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  ESCAPE 


Specific  Escape  Function  Identifier:  Set  Line  Cap 


Description: 

This  escape  function  sets  a  value  foe  the  current  line  cap.  This  value  is  to 
determine  the  shape  put  at  the  ends  of  portions  of  lines  and  curves  during 
subsequent  interpretation  of  graphical  primitives  that  use  linetype  attributes . 
See  attached  sheet  for  additional  details. 


Additional  Comments: 

The  line  cap  capabilities  proposed  here  are  adapted  from  those  in  the  PostSenp: 
language  developed  by  Adobe  Systems  Incorporated. 


Justification  for  Inclusion  in  the  Register: 

User  specified  line  caps  are  needed  to  support  the  requirements  of  office  dccu.T.e: 
exchange  and  publishing.  They  are  commonly  found  in  widely  available  proprietary 
graphics  systems. 


Relationship  to  Particular  Standards: 

1)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

2)  See  attaciied  sheet. 
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1)  CGM  Functional  Spacification  (reference  ISO  8632  CGM; 
Part  1:  Functional  Description) 


Sat  Lina  Cap  sets  the  current  line  cap  value  in  the  graphics 
state  to  the  value  specified  by  the  line  cap  indicator.  This- 
establishes  the  shape  to  be  put  at  the  ends  of  open  subpcrtions  of 
graphics  output  primitives  whose  components  are  lines  or  curves. 
The  following  line  cap  values  are  supported; 

1:  butt  cap;  the  portion  is  squared  off  at  the  endpoint  of  the 
path;  there  is  no  projection  beyond  the  end  of  the  path. 

2:  round  cap;  a  semicircular  arc  with  diameter  equal  to  the 
line  width  is  drawn  around  the  endpoint  and  filled  in  with 
the  current  line  colour. 

3:  projecting  square  cap;  the  portion  continues  beyond  the 
endpoint  of  the  path  for  the  distance  equal  to  half  the  line 
width  and  is  squared  off. 

Values  above  3  are  reserved  for  future  registration  and 
standardization,  and  negative  values  are  available  for 
implementation-dependent  use. 

A  functional  description  of  the  Set  Line  Cap  escape  parameters  is: 
Parameters : 

function  identifier  (1)  as  assigned  by  the  Registration 

Authority 

data  record  (D)  : 

line  cap  indicator  (IX) 


Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 

Integer  RL 
Integer  SL 

Data  Record  Description: 

The  parameter  defines  the  line  cap  index. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTRAN-style  pac)ced  data 
record.  T.his  is  treated  as  a  string  type  in  each  encoding  and  is 
e.ncoded  according  to  the  rules  for  string  in  that  encoding. 


1 

line  cap  indicator 
0 
0 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  2.0  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  ESCAPE 


Specific  Escape  Function  Identifier:  Set  Line  Join 


Description: 

This  escape  function  sets  a  value  for  the  current  line  join.  This  value  is  to 
determine  the  shape  put  at  corners  between  portions  of  lines  and  curves  during 
subsequent  interpretation  of  graphical  primitives  that  use  linetype  attributes. 
See  attached  sheet  for  additional  details. 


Additional  Comments: 

The  line  join  capabilities  proposed  here  are  adapted  from  those  in  the  PostSc: 
language  developed  by  Adobe  Systems  Incorporated. 


Justification  for  Inclusion  in  the  Register: 

User  specified  line  joins  are  needed  to  support  the  requirements  of  office 
document  exchange  and  publishing.  They  are  commonly  found  in  widely  available 
proprietary  graphics  systems. 


Relationship  to  Particular  Standards: 

1)  ISO  8632  (CGM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 


2)  See  attached  sheet. 
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1}  CGM  Tunctional  Specification  (reference  ISO  8632  COM; 

Part  1:  Functional  Description) 

Sat  Lina  Join  sets  the  current  line  join  state  in  the  graphics 
state  to  line  join  indicator.  This  establishes  the  shape  to  be  put 
at  the  corners  between  portions  (line  or  curve  segments)  of  line 
and  curve  graphical  output  primitives.  The  following  line  ;cir. 
values  are  supported: 

1  miter  join;  the  outer  edge  of  the  twa  portions  are  extended 
until  they  meet  at  an  angle,  as  in  a  picture  frame.  (If  the 
portions  meet  at  too  sharp  an  angle,  a  bevel  join  is  used 
instead;  this  is  controlled  by  the  miter  limit  state 
established  by  Set  Miter  Limit  escape  function) . 

2:  round  join;  a  circular  arc  with  diameter  equal  to  the  line 
width  is  drawn  around  the  point  where  the  portions  meet  and 
is  filled  in  with  the  current  line  colour,  producing  a 
rounded  corner. 

3:  bevel  join;  the  meeting  portions  are  finished  with  butt  end 
cap  (see  the  Set  Line  Cep  escape  function)  ;  then  the 
resulting  notch  beyond  the  ends  of  the  portions  is  filled 
with  a  triangle  in  the  current  line  colour. 

Values  above  3  are  reserved  for  future  registration  and 
standardization,  and  negative  values  are  available  for 
implementation-dependent  use. 

Join  styles  are  significant  only  at  points  where  consecutive 
portion  of  a  path  connect  at  an  angle;  portions  that  meet  cr 
intersect  fortuitously  receive  no  special  treatment. 


A  functional  description  of  the  Set  Line  Join  escape  parameters  is : 
Para.meters : 

function  identifier  (I)  as  assigned  by  the  Registratton 

Authority 

data  record  (D) : 

line  join  indicator  (IX) 
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Items  for  Data  Record: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 


1 

line  join  indicator 
0 
0 


Data  Record  Description: 


The  parameter  defines  the  line  join  index. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3/4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear 
encoding  (machine  independent)  of  a  FORTRAN-style  packed 
record.  This  is  treated  as  a  string  type  in  each  encoding  an 
encoded  according  to  the  rules  for  string  in  that  encoding. 

Data  Record  Description: 
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PROPOSAL  FOR  REGISTRATION  OF  GRAPHICAL  ITEM 


date  of  presentation  of  proposal  2.0  April  1987 


sponsoring  authority  ANSI 


Class  of  Graphical  Item:  ESCAPE 


Specific  Escape  Function  Identifier:  Set  Miter  Limit 


escnption: 

This  escape  function  sets  a  value  for  the  current  miter  limit.  This  value  helps 
determine  the  shape  put  at  corners  between  portions  of  lines  and  curves  during 
subsequent  interpretation  of  graphical  primitives  that  use  linetype  attributes. 
Its  purpose  is  to  place  a  limit  on  how  long  a  "splice”  can  emanate  from  the  join 
of  two  portions  of  a  line  or  curve  primitive  by  "truncating"  long  miter  joins 
into  bevel  joins.  See  attached  sheets  for  additional  details. 


Additional  Comments: 

The  line  join  capabilities  proposed  here  are  adapted  from  those  in  the  ?ostSc."ip: 
language  developed  by  Adobe  Systems  Incorporated. 


Justification  for  Inclusion  in  the  Register: 

User  specified  miter  limits  are  needed  to  support  the  requirements  of  office 
document  exchange  and  publishing.  They  are  commonly  found  in  proprietary  graphics 
systems . 


Relationship  to  Particular  Standards: 

1)  ISO  8632  (COM)  -  Specifies  a  registered  escape  as  defined  in  5.8.1. 

2)  See  attached  sheet. 
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1)  CGM  Functional  Spocification  (reference  ISO  8632  CGM; 
Part  1:  Functional  Description) 


Sat  Mitar  Limit  sets  the  current  miter  limit  value  in  the 
graphics  state  to  miter  length  specifier,  which  must  be  a  number 
greater  than  or  equal  to  1.  The  miter  limit  controls  the  treatment 
of  corners  between  portions  of  line  and  curve  output  primitives 
when  miter  joins  have  been  specified  (see  Sat  Lina  Join'  .  when 
portions  connect  at  a  sharp  angle,  a  miter  join  results  in  a  spike 
that  extends  well  beyond  the  connection  point.  The  purpose  of  the 
miter  limit  is  to  cut  off  such  spikes  when  when  they  become 
objectionably  long. 

At  any  given  corner,  the  miter  length  is  the  distance  from  the 
point  at  which  the  inner  edges  of  the  curve  or  line  portions 
intersect  to  the  point  in  which  the  outside  edges  of  the  portions 
intersect  (i.e.,  the  diagonal  length  of  the  miter).  This  distance 
increases  as  the  angle  between  the  portions  decreases.  If  the  ratio 
of  the  miter  length  to  the  line  width  exceeds  the  miter  li.mit 
parameter,  the  corner  is  treated  with  a  bevel  join  instead  of  a 
miter  join. 

The  ratio  of  miter  length  to  line  width  is  directly  related  to  the 
angle  ^  between  the  segments  by  the  formula: 

miter  length  /  line  width  »  1  /  sin  (0/^) 

Examples  of  miter  limit  values  are:  1.415  cuts  off  miters  (converts 
them  to  bevels)  at  angles  less  than  90  degrees,  2.0  cuts  off  miters 
at  angles  less  than  60  degrees,  and  10.0  cuts  miters  off  at  angles 
less  than  11  degrees.  The  default  value  of  the  miter  limit  is  10. 
Setting  the  miter  limit  to  1*  cuts  off  miters  at  all  angles  so  that 
bevels  are  always  produced  even  when  miters  are  specified. 

A  functional  description  of  the  Set  Miter  Limit  escape  parameters 
is  : 

Parameters : 

function  identifier  (I)  as  assigned  by  the  Registration 

Authority 

data  record  (D)  : 

miter  length  (VDC) 
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Items  for  Data  Record: 


If  VDC  TYPE  integer  was  selected: 


Integer  IL 
Integer  IA(1) 
Integer  RL 
Integer  SL 


Integer  IL 
Integer  RL 
Real  RA{1) 
Integer  SL 


1 

miter  length 
0 
0 

selected: 

0 

1 

miter  limit 
0 


If  VDC  TYPE  real  was 


Data  Record  Description: 


The  parameter  defines  the  miter  length. 

2)  CGM  Encodings  (reference  ISO  8632  CGM;  Parts  2,3,4) 

All  encodings  will  be  handled  in  the  same  way  -  as  a  clear  text 
encoding  (machine  independent)  of  a  FORTRAN-style  packed  data 
record.  This  is  treated  as  a  string  type  in  each  encoding  and  is 
encoded  according  to  the  rules  for  string  in  that  encoding. 
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Vin.  APPENDICES 


Appendix  A.  Extracts  from  Typical  DoD  Standards 
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MIL-STD-23B 
10  May  1984 


SVN^BOL 


INjr=S?^  =  TAT10M 


ijl- 


LIMITS  OF  BEAMS  -  CONTINUOUS  OR 
INTERCOSTAL  (CONTRACT  DRAWINGS) 
OR 

LIMITS  OF  INTERCOSTAL  BEAMS 
(SHIP  CONSTRUCTION  DRAWINGS) 


;xAxi3*r-T  I  x-<txfO*r-T 


LIMITS  OF  COf^INUOUS  BEAMS 
(ship  CONSTRUCTION  DRAWINGS) 


CO.NJTINUOUS  SHAPE  T^PO'JG’ri  PLATE 


CONTRACT  DRAWINGS; 

CXLAR  DETAILS  SPECIFIED  IN 
APPROPRIATE  SPECIFICATION 


SHIP  CONSTRUCTION  DRAWINGS: 
COLLAR  DETAILS  SHOWN  ON 
DETAIL  VIEW  AS  REQUIRED 


tcs  cclj-a:? 

S«&  25* 


SH  13028-1 

FIGURI  1.  Conventional  delineation.  -  Continued 
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Concricc  drawing  or  contract  guidance  drawing  -  deck  plan 


23  January  1963 
S'JrEHSZTING 
K:L-srz-i7A 
11  Sepiecter  19c 


MILITARY  STARLARD 
MECHANICAL  SYMBOLS 

(OTHER  THAN  AERONAUTICAL,  AEROSPACECHAFT 
AND  SPACECRAFT  USE) 


PART-1 


MIL-STD- 173-1 
23  January  1963 


EEPARTMEIiT  CF  EEFZrcSE 
WASHINGTON  25,  D.  C. 


Mechanical  Symbols  (Other 
Than  Aeronautical,  Aerospacecraft 
and  Spacecraft  Use) 

MIL-STD- 1 73- 1 

1.  This  standard  has  teen  approved  by  the 
Department  of  Defense  and  Is  mandatory  for  use  by  the 
Departments  of  the  Army,  the  Navy,  and  the  Air  Force, 
effective  23  January  1963. 

2.  Recommended  corrections,  additions,  or  deletions 
should  be  addressed  to  the  Standardization  Division,  Defense 
Supply  Agency,  Alexandria,  Virginia. 
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FOREWORD 


rvnL-STD-17B-l 
23  January  1563 


By  permission  of  the  American  Standards  Association  and  the 
American  Society  of  Mechanical  Engineers,  the  symbols  contained 
herein  have  been  adopted  vithout  change  from  the  following  American 
Standards: 

ASA  Z32. 2. 3*1949  -  Graphical  Symbols  for  Pipe  Fittings,  Valves 
(Reaffirmed  1953)  and  Piping. 

ASA  732.4-1955  -  Graphical  Symbols  for  Plumbing. 

ASA  Z32. 2. 4-1949  -  Graphical  Symbols  for  Heating,  Ventilating, 
(ReaSlTmad  1954)  and  Air  Conditioning. 

ASA  Z32.2r  6*10^  **  Graphical  Symbols  for  Heat-Power 
(Reaffirmed  1955)  Apparatus. 

ASA  732.10-1958  -  Graphical  Symbols  for  Fluid  Power 

Diagrams. 
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r.riL-STD-nB-i 
23  JanuaiT'  1963 

CONTENTS 
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2.  Graphical  symbols  for  pipe  fittings,  valves  and  piping  .— — — 

3.  Graphical  symbols  for  plumbing 

4.  Graphical  symbols  for  heating,  ventilating  and  air  conditioning 

5.  Grap.nlcal  symbols  for  heat  power  apparatus  ................ 

6.  Graphical  symbols  for  fluid  power  diagrams 
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MIL-STD-17B-1 
23  Jar.uEry  1962 


Secticn  1,  Scope. 

i  1  *:^**»<«  -/  ^.’-p ' 

*,.  -  -  C-L.^w-. ^*ic-k*iww* 

symbols  that  shall  be  used  in  the  preparation  of  drawings  when  graphic 
cr  symbolic  representation  is  desired,  for  all  items  except  aircraft, 
aercspacecraft,  or  spacecraft.  The  symbols  listed  are  those  m.ost 
commonly  em.pioyed  on  engineering  drav.-ings.  They  are  for  exterior 
and  interior  services. 

1.  2  Lim  itations.  -  Where  graphical  symibols  are  required  for  an 
item,  cr  equipm.ent  not  covered  in  this  standard,  the  form,  and  c.haracter 
of  the  sym.bcl  will  be  left  to  the  discretion  of  the  activity  concerned, 
provided  t.hat  the  symbol  used  does  not  duplicate  any  of  those  contained 
herein,  and  is  clearly  understandable,  subject  to  one  interpretation  only, 
or  explained  by  a  suitable  note  on  the  drawing  when  necessary. 

1.3  /•■pplication,  -  P-ipe  fittings,  valves  and  piping  sym.bols  (see 
section  2)  shall  be  used  for  all  systems,  except  w.here  so  desired,  the 
sym.bols  shown  for  fluid  power  systems  (see  section  6)  may  be  used  for 
fluid  power  system^s.  All  other  symbols  shall  be  used  as  applicable. 

1.  4  Use.  -  Each  drawing  or  one  sheet  of  each  set  of  drawings  on 
which  sym.ools  are  used  shall  show  a  legend  which  shall  identify  the 
sym.bols.  However,  those  sym.bols  wnich  are  unm.istafcably  identified 
on  the  drawing  by  the  text  or  note  at  or  near  the  sym.bcis,  m.ay  be 
cm.itted  in  the  legend.  In  lieu  of  identifying  each  sym.bcl,  it  is  perm.issible 
to  state  mat  sym.bols  used  are  in  accordance  with  this  Standard  or  the 
appropriate  A.  m.erican  Standards.  Since  sym.bolic  representation  does  not 
usually  involve  exact  or  scale  layout  cr  the  actual  run  cr  leads  of  piping,  t.he 
sam.e  sym.ool  m.ay  be  used  for  all  projections  cf  t.he  system,  (plan, 
eievatic.ns  and  sections)  except  where  specific  sym.bols  for  the  various  views 
are  included  in  this  standard. 
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23  o’^ar.-ary  laicS 

S'^c'.lon  6  -  Grapnlsal  sysScIs  izT  flali  pcwer  diagrams,  extrac-.od  from 
ASA  ?-bllca:lsr.  Y22.1C; 

3. 1  T".'.a  section  shoa-s  tne  tcs'.c  sytrbo’.s,  describes  the  prlnrlrles  cr.  whlcb 
tne  symbols  are  based,  and  ill-strates  soma  representative  composite  symbols. 
Cocpcsiie  symbols  can  be  devised  tor  any  il-id  power  compcneiu  by  c.mo..-.lng 
basic  symbols.  A  symbol  is  considered  to  be  the  lines,  letters  and  abbreviations 
wnich  identify  purpose  and  method  of  operation  of  component  represented,  and 
symbols  only  are  standardized  in  this  section.  Component  data  are  added  to 
symbols  when  used  in  circuit  diagrams  and  consist  of  names  of  ports  and  control 
elements,  notes  regarding  pressure  and  flow  rate  settings  a.nd  other  expla.natory 
dau. 


6.2  Symbol  rules.  The  following  rules  are  applicable  to  graphical  symbols 
for  fluid  power  diagrams: 


(a)  Symbols  show  connections,  flow  paths  and  function  of  component 
represented.  They  do  not  Indicate  conditions  occuring  durl.-.g 
transition  from  one  flow  path  arrangement  to  another.  Further, 
they  do  not  Indicate  construction,  or  values  such  as  pressure, 
flow  rate,  and  other  component  settings. 

(b)  Symbols  do  not  indicate  location  of  ports,  direction  of  shlftlm  of 
spools,  or  position  of  control  elements  on  actual  component. 

(c)  Symbols  may  be  rotated  or  reversed  without  altering  their 
meaning  except  in  the  cases  of: 

(D^Llr.es  to  reservoir.  6. 3. 7.1  and  6. 3. 7. 2 
(2)  Vented  manifold,  6. 8. 3 

(d)  Line  width  does  not  alter  meaning  of  symbols. 

(e)  Symbols  may  be  drawn  any  suitable  size.  Size  may  be  varied 
for  emphasis  or  clarity. 

(f)  Letter  combinations  used  as  parts  of  graphical  symbols  are  not 
necessarily  abbreviations,  provided  l.'.eir  rr.eanin^  is  clearly 
ur.dersiandaole  and  subject  to  one  interpretation  only  or 
explained  by  a  suitable  note  or  tabulated  legend  or.  the 
drawing  w'ner.  necessary. 

(g)  'Vr.ere  flow  lines  cross,  a  loop  shall  be  used  except  vithln  a  symbol 
envelope.  Loop  may  be  used  in  this  case  If  c.arlty  is  Improved. 

(h)  In  multiple  envelope  symbols,  flow  condition  shown  nearest  a 
control  symbol  takes  place  when  that  control  is  caused  or  permitted 
to  actuate. 

(1)  Each  symbol  Is  dra-wn  to  shew  normal  or  neutral  condition  of 

component  unless  multiple  circuit  diagrams  are  furnished  snowing 
various- phases  of  circ-it  operation. 

(j)  Arrows  shall  be  used  witnlr.  symbol  envelopes  to  show  direction  of 

flow  path  In  coxpcr.ent  as  used  in  the  application  represented. 
Doutle-er.i  arrow  snail  be  used  to  Indicate  reversing  flow. 

(k)  External  ports  are  where  flow  lines  connect  to  basic  symbol,  except 
where  component  enclosure  Is  used. 


£x:err.a.  ports  are  at  lnterseotlor.s  of  f.ow  IL-.ss  and 
enclosure  symbol  wnen  enclosure  is  used. 
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Appendix  B.  PostScript  and  Interpress  Capabilities 
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PostScript  Procedures  and  Interpress  Symbols 

4 
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POSTSCRIPT  Procedures 

A  PostScript  procedure  is  a  set  of  operations  grouped  together 
with  a  common  name.  This  set  of  operations  is  stored  with  its 
key  in  a  dictionary.  When  the  key  appears  in  a  program,  the  as¬ 
sociated  set  of  operations  is  carried  out. 

PostScript  procedures  are  defined  in  exactly  the  same  way  as 
variables.  The  program  must  place  the  procedure  name  (preceded 
by  a  slash)  on  the  stack,  followed  by  the  set  of  operations  that 
make  up  the  procedure.  Then  the  dcf  operator  is  used  to  store  the 
operations  and  name  in  the  current  dictionary.  The  set  of  opera¬ 
tions  making  up  the  procedure  must  be  enclosed  in  braces. 

For  example,  the  following  line  defines  a  procedure  named  inch. 

/inch  {72mul}  def 

Any  appearances  of  the  word  inch  following  this  line  will  cause 
the  interpreter  to  carry  out  the  operations  inside  the  braces.  That 
is.  the  interpreter  will  put  72  on  the  stack  and  then  multiply  the 
top  two  numbers,  the  72  and  whatever  was  on  the  stack  when 
inch  was  called.  Thus,  the  program  lines 

5  inch 
5  72  mul 

have  identical  results;  both  leave  360,  the  product  of  5  and  72.  on 
the  stack. 

The  inch  procedure  is  a  useful  tool  in  many  programs,  since  it 
translates  inches  into  the  1/72-inch  units  of  the  PostScript  co¬ 
ordinate  system. 
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4,3  USING  PROCEDURES  AND  VARIABLES 


The  use  of  procedures  and  variables  can  make  an  enormous  dif¬ 
ference  in  the  readability  of  a  program,  the  ease  with  which  it 
can  be  modified,  and  its  length. 


Overlapping  Boxes 


Three  Boxes  Again 

As  an  example,  let  us  take  the  last  program  from  chapter  two.  the 
three  overlapping  boxes,  and  rewrite  it.  Looking  over  the 
program,  we  see  that  the  set  of  instructions  that  construct  a  one- 
inch-square  path  is  repeated  three  times.  Let  us  define  these  in¬ 
structions  to  be  a  procedure  named  box  and  then  incorporate  this 
procedure  into  the  program. 

%  —  Define  box  procedure  — 

/box 

{ 72  0  rtineto 
0  72  nineto 
-72  0  rtineto 
ciosepath }  def 

% - B^in  Program - 

newpath  %  First  box 

252  324  moveto  box 
0  setgray  fill 

newpath  %  Second  box 

270  360  moveto  box 
.4  setgray  till 

newpath  %  Third  box 

288  396  moveto  box 
8  setgray  fill 
showpage 

Here  we  start  by  defining  our  new  procedure,  box.  to  be  the  set 
of  operators  that  create  a  square  path.  We  then  use  that  procedure 
three  times  to  make  three  filled  boxes.  First  we  move  to  a  stan- 
ing  point  on  the  current  page.  Then  we  call  the  box  procedure, 
which  contructs  a  path  staning  at  that  point.  Finally,  we  set  the 
gray  value  and  fill  the  path  we  contructed.  These  steps  are 
repeated  two  more  times,  once  for  each  box  in  our  image. 
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Instancing 


The  concepa  of  jymAo/  and  insianet  arc  provided  la  latcrprcs  by  compoicd  opcracon  aad 
craasforeuuoio.  A  (raphtcaj  symbol  caa  be  deAacd  ae  a  conpoicd  operator.  Wtica  an 
msiaacc.  or  copy,  of  the  symbol  la  to  be  pnattd  the  curretu  aaas/btmaooa  *ill  be  applied  to 
all  coordtaaccs  aa  dte  symbol  eaUa  uaaicr  operaton.  The  propetma  of  the  currem  traaafotma' 
oon  «tll  thus  determine  the  position,  sue,  aad  rotadoa  of  the  laaaacc  on  the  pnntcd  pape. 

The  pnneipal  use  of  symbols  and  instances  in  Interpress  is  Ibr  pttadni  charaeten.  Each  charac¬ 
ter  IS  defloed  by  a  composed  operator,  eaued  a  c/uraettr  optmor.  These  operators  arc 
invoked,  usually  by  show,  with  a  current  traasfbrmaaoa  that  achieves  the  proper  sue.  onenta* 
tion.  aad  position  of  the  character. 

Instancuit  caa  also  be  used  Ibr  other  purposes.  Graphical  objects  that  arc  repeated  often  on  a 
pape  or  throughout  a  document  may  be  trsaiad  as  instances.  A  symbol  a  deftaed  ■  a  com¬ 
posed  operator  and  called  with  aa  appropnaie  current  traaiftirmadoa  la  order  to  gcacrau  each 
lastaacc.  Since  show  may  not  be  the  best  operator  to  cflkn  ibcso  ealla  other  pnmioves  are 
available  at  well 


14.1  Deflninf  symbob 


A  symbol  is  sunply  a  composed  operator  that  calls  imager  operaton  to  eorstruct  a  graphical 
symbol.  The  symbol  espresies  coordinates  in  a  eoordinau  system  of  us  own  choice,  sometimes 
called  (he  tymba!  coonfinere  tysttm.  Figure  U.l  shows  a  nek  ffgurc  and  ao  aatonated  coor¬ 
dinate  system.  Eiample  14.1  shows  how  this  symbol  could  be  deftnod  at  a  composed  operator. 
To  Inierprcss.  (his  symbol  is  sunply  a  composed  operator.  Its  efTccuve  use  as  a  symbol  depends 
on  the  ways  in  which  the  master  calls  the  composed  operator. 
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Ias(jac'.o( 


Figure  U  l.  \  4cflned  ■;>  •«!  cvirisite  sv^'en 


14.2  Making  instances 

la  order  to  piece  an  uuience  of  a  tymbol  on  (Ac  page,  we  «iU  need  to  lue  a  tnuformauon  to 
control  the  «ue.  rouuon.  and  locauon  of  cite  instance.  Thu  transformation  u  retponsisie  for 
mapping  (Von  the  symbol  coordinate  system  to  the  current  coordinate  system,  une  one 
esublished  by  r.  As  we  observed  in  Secuon  6.2.  it's  common  to  esubhsh  a  page  coordi.'.ate  sys¬ 
tem  chat  has  a  conveoicnt  ongin  and  units  of  measuremeoL  The  examples  m  thu  sccucn  will 
assume  a  page  coordinau  system  as  in  Example  6.1.  which  uses  units  of  10*’  meter. 

When  we  establish  the  tymbal-to*page  iraasfonnation.  it  u  usually  helplVtl  to  break  the  tnns- 
formauoa  down  into  two  components:  (t)  a  translaboa.  which  u  used  to  deurmine  where  the 
origin  of  the  symbol  coordinate  system  will  be  on  the  page  coordinate  system,  and  (2)  a  scaiing 
and/or  roucton  transformauoa  that  deurmmes  the  sue  and  rouuon  of  the  instance  witn 
respect  to  la  origin. 

Suppose,  fbr  example,  that  we  want  instances  of  the  sock  ffguie  in  Example  U.i  to  be  10  cm. 
hi^  flrom  toe^to  head.  Since  10  cm.  u  10000  unta  in  the  page  coordinate  system,  and  since 
the  head-wtoe  distance  is  9  unis  m  the  symbol  coordinate  system,  the  scale  to  convert  trom 
symbol  to  page  coordinates  wiu  be  10000/9. 

The  (bUowing  master  prints  mo  instances  of  the  symbol,  with  the  same  sues,  with  or.gins  ft 
xaS  cnu  cm.,  and  at  xalS  cm..  /■  8  cst: 


'  I 

I  I 


*1 


F’gure  la  2.  Two  msunces  of  a  svmSol. 
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Line  13  tlcen  ‘Jie  current  cransformauon  to  that  coorOinatet  m  *ite  t)'inbol  will  be  subjected 
first  to  a  Kalmi  transformauon.  tfica  a  tnnsiauon.  and  finally,  to  the  pace  transfomtation. 
Line  U  could  equally  w«u  be  wnctcs  at  <{  10000/9  scale  SOOO  SOOO  nUNSLAiT  concaTT 
concaTT  13  FCer  oo  }>.  but  could  <w(  be  wnncts  at  <{  10000/9  scau  concatt  SOOO  SOOO 
tkavslatc  comcatt  13  FCCT  OO  }>  beuute  this  would  chanic  the  order  of  applicauon  of 
transformaoons.  However,  the  IbUawins  vatunt  would  do: 

tA  3.  r«oi4ca<®tAt  fa>*  liA«  13  4a  (stiAti®  tA  I** 

(  9dCC  1055  rRAMSwAre  COMCATT  td0QC/«  SCALC  COMCArT  13  Kir  00  >  OOSAVtSZMAcIBOOt 

You  should  see  clearly  how  this  is  equivalent  to  the  orstiaal  line  13.  Lindcnundini  the  order 
of  application  of  iransformauoos.  and  bow  innsfbimaooni  ate  coocaicnated  onto  r.  is 
extremely  ufi.sortanL 

Note  the  use  of  oosaveslmfuiooy  to  save  and  restore  the  current  nasformauon.  At  the 
betmnini  of  line  L3.  <he  euireat  tnasfotmauon  csublishes  the  page  coordinate  system. 
Beuust  of  the  satmi  and  rtstonni.  this  same  system  will  also  be  in  effect  after  line  13  is 
executed.  If  the  transformauon  were  not  restoiecL  the  CONCaTT  openoon  on  line  13  would 
have  a  permanent  effect  on  the  current  transforeuucn.  Icavini  it  m  the  symbol  coordmate 
system  associated  with  the  first  instaacc  of  the  suck  ficure. 


An  aitemauve  «ay  to  call  an  instance  is  to  use  the  current  posiuon  and  move  or  'nu>s  to 
accomplish  ihe  translauon  iransformaoon.  Example  lk.3  could  be  modified  to  read: 

u  t.  rvei KWient  far  Hit*  is  t*  Iiawfl*  t*  t** 

(  scao  s««o  strtT  aovt  taoso/s  scan  coscatt  u  rctr  go  >  oosavtsiMeteiooT 
Or.  after  one  muior  chanfe.  to  read; 

l<  S.  '••’(ceoent  tar  ii««  IJ  m  (iiaal*  la 
SOOO  1003  SITIV 

(  -Ovt  .3330/9  son  COncarT  IS  rcir  oo  1  oosavfsrwntoor 

If  we  'e  }oing  to  make  lots  of  instances  of  the  symbol  with  the  sane  site  and  oner.ii'-v’n  Utis 
f-rn  has  a  nice  property  line  I3b  will  be  die  same  for  each  insunce  because  k  crhti..-;s  .lo 
pcsit.cr.'.r.g  ;nf:tmauon  Pus  suggests  denning  a  composed  operator  to  achie-e  t.he  erTc;i  of 
;.ne  .it  fc.xi-rp  e  las  resjies  -he  masier  m  E«a.mple  la;  to  use.Lh.s  idea 
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This  «xampl«  looki  a  tot  like  (&<  way  eharaectr  optraton  work!  Tht  eompoMd  operator  coo* 
itrucud  ui  ime?  I  to  10  cormponpa  to  a  character  operator,  deftned  in  (Ae  character  coor* 
dinate  ty«em.  The  compoied  operator  coowucted  m  tinea  U  to  13  eomaponds  rou|ht>  to  the 
operator  created  by  xooirrravr.  which  cootrola  the  acale  and  rouuon  of  the  inauoce.  The 
lavoeation  of  the  operator  by  Ant  leiung  the  cutrent  postion  to  the  dcaired  ortgin  of  the 
tnitance  aad  then  cailini  an  appropnate  operator  (imes  16  and  17)  carreipondi  reu|hiy  to  the 
way  strXY  aed  show  are  used  for  charactets. 

The  basic  Intcrpreis  facilities  of  composed  operaton  aad  traasfeimauons  allow  a  great  deal  of 
AeaibUicy  in  deAaiag  and  using  tymboli  including  applications  we  have  not  illustrated. 
Symbols  may  of  course  be  rotated  as  well  as  sealed.  Svirbols  can  call  other  S)mbols.  nesung  to 
an  arbitrary  depth. 
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6.1  INTRODUCTION 

This  chapter  contains  detailed  information  about  ail  the  standard 
operators  in  the  PostScript  language.  It  is  divided  into  two 
parts. 

First,  there  is  a  summary  of  the  operators,  organized  into  groups 
of  related  functions.  The  summary  is  intended  to  assist  in  locat¬ 
ing  the  operators  needed  to  perform  specific  tasks. 

Second,  there  are  detailed  descriptions  of  ail  the  operators,  or¬ 
ganized  alphabetically  by  operator  name.  Each  operator  descrip¬ 
tion  IS  presented  tn  the  following  format: 

operator  operand,  operand,  ...  operand^  oporator  result,  ...  result,,, 

Detailed  explananon  of  the  operator 
EXAMPLE: 

An  example  of  the  use  of  thts  operator  The  symooi  » 
designates  values  left  on  the  operand  stacH  Oy  the  example. 

ERRORS: 

.A  list  of  the  errors  that  this  operator  might  execute 

SEE  ALSO. 

.A  list  of  related  operator  names 
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At  the  head  ot  an  operator  description,  operand ^  through 
operand^  are  the  operands  that  the  operator  requires,  vnth 
operand^  being  the  topmost  element  on  the  operand  stack.  The 
operator  pops  these  objects  from  the  operand  stack  and  con¬ 
sumes  them.  After  executing,  the  operator  leaves  the  objects 
result^  through  result^  on  the  stack,  with  result^  being  the  top¬ 
most  element. 

Normally  the  operand  and  result  names  suggest  their  types.  For 
example,  num  indicates  that  the  operand  or  result  is  a  number,  mt 
indicates  an  integer  number,  any  indicates  a  value  of  any  type, 
and  proc  indicates  a  POSTSCRIPT  procedure  (i.e..  an  executable 
array).  The  noution  'bool\int'  indicates  a  value  that  is  either  a 
boolean  or  an  integer.  Names  representing  numbers  sometimes 
suggest  their  purpose.  e.g..  .c.  y.  or  angle.  A  matrix  is  an  array  of 
six  numben  describing  a  transformation  matrix  (see  section  4.4). 
A  font  is  a  dictionary  constructed  according  to  the  rules  for  font 
dicttonaries  (see  section  S.3). 

The  notation  indicates  the  bottom  of  the  stack.  The  notation 
in  the  operand  position  indicates  that  the  operator  expects  no 
operands,  and  a  in  the  result  position  indicates  that  the 
operator  returns  no  results. 

The  documented  effects  on  the  operand  stack  and  the  possible 
errors  are  those  produced  direaly  by  the  operator  itself  Many 
operaton  cause  arbitrary  POSTSCRIPT  procedures  to  be  invoked. 
Obviously,  such  procedures  can  have  arbitrary  effects  that  are 
not  mentioned  in  the  operator  descriptions. 
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Operand  stack  manipulation  operators 


any 

pop 

- 

discard  too  siemeni 

any,  any. 

Men 

any,  any, 

•xcnange  too  two  wements  rsr 

any 

dup 

any  any 

duoticat*  lop  •lamant  tad 

any.  any,  n 

copy 

any,,  any,  any,  any. 

duoacaie  too  n  aiomants  tjr 

any,  any, n 

indea 

any,  any,  any. 

dupiicata  aroitrary  siamant  1 72 

a,.,  a,  n. 

roll 

^  '  <  ‘•*00  "  ^  ^  ***00  ** 

roll  n  elements  uo  /  times  20S 

-  any,  any. 

ciMr 

— 

discard  aii  elements 

-any,  any. 

count 

-  any,  any^  n 

count  elements  on  stack  132 

- 

mark 

mark 

push  mani  on  stack  184 
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marK  00),.  0D|,  eiMftoiiwili  -  aiscara  wamanis  oown  mrou^n r^r 

fflafK  ooi.  oot,  counttemark  mam  aoi.  ad),  n  ccum  «i«m«nts  aown  to  mar*  *33 


Arithmetic  and  math  operators 


num.  num. 

add  sum 

num.  plus  num,  11 5 

num,  nuntj 

dhr  quonant 

num.  oiviaad  by  num,  ras 

ml,  ifiij 

tdiv  quotwnt 

mtagar  dnrxsa  168 

int,  inij 

mod  ramamdar 

mr,  moo  intj  rss 

num,  nu/Tij 

mul  product 

num.  nmas  num,  186 

num,  num^ 

lub  dittaranca 

num,  minus  num,  230 

num, 

aba  num. 

aosoiuta  vaiua  of  num,  f  >5 

num. 

ttag  num, 

naganva  of  num,  i87 

num, 

caMne  num. 

calling  of  num,  12S 

num, 

floor  num. 

floor  of  num,  1S7 

num. 

round  num. 

round  num,  to  naarast.mtagar  206 

num, 

truneala  num. 

ramova  fractional  part  of  num,  23d 

num 

aqrt  raal 

SQuara  root  of  num  22* 

num  dan 

atan  angia 

arctangam  of  nurrrdan  m  dagraat  ’2’ 

angla 

eoa  raal 

coama  of  angia  (Oagraat)  132 

angta 

am  raal 

sma  of  angia  (daqraaai  223 

daaa  axponant 

axp  raal 

raiaa  baaa  to  axponanr  powar  t54 

num 

In  raal 

natural  loganthm  (baaa  at  100 

num 

lod  raal 

logantnm  (baaa  lOt  i$i 

- 

rand  mt 

ganarata  pi audo -random  intagar  197 

'  int 

arand  - 

sat  random  numear  saad  22* 

- 

rrand  mt 

raium  random  numoar  saad  207 

Array  operators 

int 

array  array 

craata  array  at  langm  mt  120 

- 

(  mam 

Stan  array  construcnon  f  13 

mam  ot>iQ..om,., 

I  array 

and  array  conatnjciion  1 13 

array 

langtn  mt 

numoar  ot  atamans  m  array  r  .rg 

array  mdax 

got  any 

gat  array  aiaman  mdaxad  by  irroox  r64 

array  mdax  any 

put  - 

put  any  into  array  at  mdax  795 

array  mdax  count 

gatmtarval  subarray 

subarray  ot  array  starting  at  rnodx  for  counr 
atamans  7S5 

array,  mdax  array^ 

putmtarval  - 

ragiaca  subarray  of  array,  starting  at  mdax 
by  array,  f96 

array 

a(,..a,,,  array 

Dusn  all  aiamans  ot  array  on  stack  t  f  5 

any,,  any,,,  array 

aatora  array 

POO  aiamanTS  from  stack  mto  array  7^7 

array,  array. 

copy  subarray. 

copy  aiamants  of  array,  to  initial  suoarray 
of  array,  Ijl 

array  oroc 

forall  - 

oxacuia  proc  tor  sacn  aiamant  ot 

VTVf  rgt 
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Dictionary  operators 


■m 

diet  diet 

create  dietionary  «iirr  caoacity  'or  n> 

eiamants 

diet 

langth  >ni 

numoar  of  Kay-valua  pairs  m  oia  '  '9 

diet 

maxlangtli  mt 

capaoty  of  OKt  fS5 

diet 

bagin  - 

pusn  oict  on  diet  stacx  '24 

- 

and  - 

pop  dKt  stack  r49 

key  valua 

daf  - 

assooata  nay  and  vaiu0  m  current 
diet  f45 

Kay 

load  vaiua 

saaren  diet  stack  tor  key  ana  return  assoo- 
atad  vaiua  fdf 

Kay  vaiua 

atora 

rapiaca  topmost  definition  of  xay  22^ 

diet  Kay 

gat  any 

gat  vama  associated  witn  itay  >n  okt  f64 

diet  Kay  vaiua 

put  - 

associate  nay  mntn  va/ua  m  oia  i95 

diet  Kay 

known  eool 

test  wnoinar  key  is  m  OKt  f  77 

Kay 

wtiara  diettrua 

ortataa 

find  dia  m  einicn  key  is  daknad  230 

diet,  diet. 

eapy  diet. 

copy  contents  o(  eser,  to  diet,  f  3f 

diet  proe 

foraH  - 

axacuta  proe  tor  aacn  alamant  of  diier  f6f 
pusn  arrordlet  on  operand  stack  f5t 

* 

- 

lyiwwioiCi  Qicc 

pusn  syslamdiel  on  operand  stack  23f 

- 

uaatdlct  diet 

pusn  uaafdlet  on  operand  stack  230 

'4 

eurrontdiet  dio 

pusn  currant  diet  on  operand  stack  134 

countdictatack  int 

count  aiemants  on  diet  stack  133 

array 

dtctatack  suoarray 

copy  det  stack  into  array  147 

String  operators 

int 

string  stnng 

craata  stnng  of  langtn  mr  220 

string 

langtfi  mt 

number  of  aiemants  m  string  f  79 

stnng  indax 

gat  int 

gm  stnng  eiamant  indexed  by  mopx  164 

stnng  indax  ini 

put  - 

put  mr  into  stnng  at  mdax  195 

stnng  indax  count 

gatlntarvat  substnng 

substnng  ot  stnng  starting  at  mdax  for 
eouw  aiamams  f05 

stnng,  indax  stnng. 

pudntarval  - 

reoiaca  substnng  ot  stnng,  starting  at  mdax 
by  string,  i96 

stnng,  stnng. 

copy  substnng, 

copy  eiamants  ot  stnng,  to  initial  substnng 
of  smng,  131 

stnng  proe 

forad  - 

axacuta  proe  for  aacn  element  of 
sinng  rgr 

stnng  saaK 

ancfioraaareX  oost  maicn  tnj* 

or  stnng  falsa 

datarmna  >  seek  is  initial  substnng  of 
stnng  1  rg 

stnng  saaK 

saareft  oost  maten  pra  trua 

or  stnng  faisa 

saaren  for  seek  in  stnng  2’  i 

stnng 

tokan  post  toxan  irua 

or  faisa 

read  token  from  start  or  stnng  232 
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Relational,  boolean,  and  bitwise  operators 


any.  anyj 

aq  booi 

test  eouai  'SO 

any.  anyj 

no  bool 

test  not  eouai 

num.  Str.  nufTij.str, 

go  boot 

test  greater  or  equal  >63 

num,  Str,  nurPj.strj 

gt  boot 

test  greater  man  >6' 

num,isir,  numjistTj 

lo  bool 

teat  leaa  or  equal  t79 

num,istf.  nuttijistfj 

n  boot 

test  less  man  ia2 

t)ooi,|int,  Oooijlintj 

and  bod, lint, 

logical  1  biMnao  and  r  i6 

aooi.iim, 

not  bod2;im, 

logical  1  biiwtso  not  i89 

eooijlintj 

or  bod,|int. 

logical  1  biMnso  inclusive  or  i9i 

bool,  lint,  booijiintj 

xor  bod,|int. 

logKal  1  bitwise  exclusive  or  2a  t 

- 

truo  truo 

pusn  bodoan  value  mj»  23* 

- 

tatao  laiso 

push  bodoan  value  ta/se  tSS 

int,  snft 

bttaliM  mt. 

bitwiso  snm  of  mt,  (positive  is  >eft)  i2S 

Control  operators 

any 

oaoe  - 

execute  aitMrary  odect  fS2 

bool  prac 

u  - 

executa  proc  if  boor « truo  rtfp 

bool  proc,  prac. 

HWao  - 

execute  proc,  if  bod  is  true,  proc,  if  bod  is 
talas  tS9 

imt  incr  limit  proc 

for  - 

execute  proc  with  values  from  imt  by  stops 
of  irwrto  Htnt  ISO 

intproe 

rapaat  - 

execute  proc  inromaa  202 

'proc 

loop  - 

exscuio  procan  inoafimta  numoar  of 
bmos  182 

- 

oaN  - 

exit  innermost  activo  loop  15* 

- 

atop  - 

tarmmato  olappod  context  228 

any 

atoppod  bod 

osiabiisn  context  lor  coKiang  slop  22? 

- 

couniOBOcatocit  mt 

coum  eiemenis  on  exec  stack  i33 

array 

oxocitocft  subarray 

copy  exec  stack  mto  array  1S2 

- 

qutt  - 

terminate  interpreter  i9? 

- 

aton  - 

executed  at  interpreier  startup  225 

Type,  attribute,  and  conversion  operators 

any 

typo  namo 

return  name  identifying  anya  type  235 

any 

evUt  any 

make  obiect  bo  literal  tat 

any 

eva  any 

make  obieci  bo  exacutado  tea 

any 

aCfWCH  OOQt 

tost  executable  aimbuto  2*0 

arrayitiiaittnng 

oaocutoordy  arrayifiloistnng 

reduce  access  to  exocute-oniy  '52 

arrayiOiciihioisinng 

noooeooa  anayldictifiioistnng 

OisaHow  any  access  '55 

arrayiOictitiloistnng 

roodordy  arrayidictifiloistnng 

reduce  access  to  reao-oniy  200 

arrayidictifiiaistnng 

rcttoek  bod 

tost  read  access  i98 

arrayidioiMaistnng 

wenoek  boot 

test  wnte  access  238 

numistnng 

cvi  mt 

convert  TO  mteger  ta  t 

string 

cvn  namo 

convert  to  name  i*2 

numistnng 

cvr  root 

convon  to  real  ta2 

num  radix  stnng 

evra  substnng 

convert  to  stnng  wim  radix  i43 
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any  stnrig 

eva  suosrnng 

convert  to  stnng  '44 

File  operators 

string,  stnngj 

fila  fila 

Open  file  lOantifiad  oy  stnrtg^  wim  access 
smnpj  155 

hia 

cioaaMta 

aosa  file  i29 

file 

read  mt  trua 

or  faisa 

read  one  character  from  fiit  iga 

Nia  int 

wrtta  — 

«*me  one  character  to  fil»  239 

III#  stnng 

raadfiaaatnng  suOstnng  boot 

read  hex  from  Me  mto  stnng  igg 

ftia  stnrtg 

writatiaaatnng 

amta  stung  to  tils  u  hex  240 

til#  stnng 

raadatrtng  substnng  oool 

read  stnng  from  tSia  20i 

fit#  stnng 

wrltaatring  - 

amta  charaenrs  of  stnng  to  Afa  240 

til#  stnng 

raadlina  substnng  bool 

read  Ima  from  fils  mto  stnng  200 

tile 

tokan  token  true 

or  falsa 

read  tokan  from  fNa  232 

fila 

bytaaavaNaWa  int 

numbar  of  byiaa  avariabia  to  rood  i25 

* 

IhjaR  - 

sand  buflarad  data  to  standani  output 

No  158 

fila 

fluaMlla  - 

sand  buffarod  data  or  road  to  EOf  t58 

fila 

raaaWHa  - 

diacard  buMorad  charactara  202 

fila 

slaliM  bool 

return  siaBM  of  file  228 

*  stnng 

run  - 

axacuta  oontants  of  named  fHa  202 

- 

eurrantflla  fila 

return  tMo  eunandy  oamg  axacutod  135 

stnng 

print  — 

wnia  charactors  of  stnng  to  standard  output 
ns  fS9 

any 

a  - 

mita  text  roptaaamabon  Of  arty  to  standard 
output  fHa  114 

-  any,  any. 

Stack  1-  any, ..  any. 

print  stack  nondaainjctivaly  uawig  >  224 

any 

aa  - 

mita  syntactic  rspraeantation  of  any  to 
standard  output  nia  1 14 

-  any,  any. 

pataek  i-  any,  .  any. 

print  stack  nondastnjcavaty  using  »  194 

■ 

prompt 

axecutao  wnsn  ready  for  intaractwa 
inpu  194 

bool 

adw  - 

turn  orvoff  echoing  149 

Virtual  memory  operators 

- 

sava  sava 

create  VM  snapshot  20$ 

sava 

rastora  - 

restore  VM  snapshot  203 

- 

vmatatua  lavai  used  maximum 

ropon  VM  status  238 

Miscellaneous 

operators 

proc 

Mnd  oroc 

rapiaca  operator  names  m  proc  by 
operators  124 

- 

null  null 

push  null  on  operand  stack  1S9 

- 

uaartlma  >nt 

return  time  m  mniisaconds  237 

- 

varaion  stnng 

intarprotar  version  237 
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Graphics  state  operators 


- 

gsava 

save  graonics  state  '56 

- 

graatora 

restore  grapmcs  state  '65 

- 

graatoraali  - 

restore  to  txittommost  graonics  state  >66 

- 

initgrapRiea  - 

reset  graprttcs  state  paramatars  >  T3 

num 

aatUftawMIh  - 

sat  line  widm  219 

- 

eurrandinawMtti  num 

raium  currant  line  vmdtn  137 

int 

aatllnaeap  - 

sat  snaoa  ot  ime  ends  tor  stroxa  iO>oun. 

1  around.  2>squara)  2i7 

- 

currantlinaeap  <nt 

return  current  line  cap  tJ6 

int 

aadinaioin  - 

sat  snaps  at  comers  tor  stroxa  (Oamitar. 

1  >round.  2abavai)  218 

- 

cunamMna<o>n  im 

return  currant  line  |Otn  137 

num 

aaonHartlmit  - 

sat  mitar  length  limit  220 

- 

currantnMtarHinM  num 

return  curram  mitar  limit  137 

array  otfsM 

aatdaan  - 

sat  dean  paitsm  tor  stroking  214 

- 

curranWaali  array  ottaat 

rmum  currant  dash  paiism  iM 

num 

aaim 

sat  liemasa  toiaranca  2iS 

- 

curranlflM  num 

return  currant  tiatnaas  135 

num 

aalgray 

sat  color  to  gray  vaiua  from  0  ibieck)  to  i 
(whita)  218 

- 

eurrantgray  mim 

return  currant  gray  i38 

hu«  Mtjbrt 

aaihabcotor 

sat  color  given  hue.  saturation. 

Onghtnaaa  2i8 

eunanthaiNXMor  huasattxt 

rmum  currant  color  hue.  seturaeoo. 
onQnmvM  tjo 

rad  graan  otua 

aatrgpcdtof 

sat  color  given  rad.  graan.  bkia  22i 

- 

eunantrgaeolar  rad  graan  Wua 

return  currant  color  rad.  graan.  tHua  138 

fraq  angta  proe 

aatacraan  - 

sat  heittona  screen  221 

- 

currantacraan  traq  angia  proe 

return  currant  halftona  screen  139 

proc 

aadfartalaf 

sat  gray  transfer  function  222 

- 

curranttranafar  proc 

return  currant  transfer  function  f^ 

Coordinate  system  and  matrix  operators 

- 

matrix  matnx 

create  identity  matnx  i84 

- 

initmatrix  > 

sat  CTM  to  daviea  default  1 74 

matnx 

idantmatrix  matnx 

fill  main*  with  identity  transform  i67 

matnx 

dafaultmatrlx  matnx 

fill  marrx  with  device  default  matnx  i45 

main* 

currantmatrix  matnx 

fill  mainxwitn  CTM  137 

matnx 

aatmatrix  - 

replace  CTM  oy  matnx  2i9 

V 

tranatata  - 

translate  user  space  oy  if,,  233 

t  t  matn* 

*  -1 

tranaiata  matnx 

aafina  translation  oy  if,,  233 

<•<. 

acaia  - 

scale  user  space  oy  s,  ano  5,  209 

s  s  matnx 

*  t 

scaia  matnx 

oafina  seating  oy  s,  and  $,  209 

angia 

rotate 

rotate  user  soaca  oy  angia  degrees  206 

angia  matnx 

rotate  matnx 

define  rotation  oy  angia  oagraas  200 

matnx 

eeneat  - 

rapiaca  CTM  by  matnx  x  CTM  130 
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wKltn  ri«ight  invert  matnx  oroc  Imagemaak 


renaer  masK  onto  current  oage  ’ 't 


Device  setup  and  output  operators 


- 

shoiwpage  - 

Output  and  reset  current  oage  333 

- 

copypage  - 

Output  current  page  ^33 

matnx  vmdtii  neigtn  proc 

banddavtea  - 

install  oand  Puffer  davica  ’23 

matnx  width  height  proc 

framadaetca  - 

install  frame  ouffer  device  f  62 

- 

nulMaelea  - 

install  no-output  davica  ’90 

proc 

randarbanda  - 

enumerate  oands  tor  output  to  device  20’ 

Character  and  font  operators 

)<ev  tom 

daflnafont  font 

register  font  as  a  tom  dictionary  f45 

xey 

findtont  tom 

return  font  diet  identified  Oy  xay  iS6 

tom  scale 

aeatatant  tom' 

scale  tom  oy  scale  to  produce  new 
tonr  2’0 

tom  matnx 

makafont  tom' 

transtorm  font  by  matnx  to  produce  new 
tonf  i$3 

tom 

aatfont  - 

sat  fom  dictionary  2i$ 

- 

cwTonWont  tom 

return  currant  tom  dtobonary  ’36 

string 

allow 

pnm  characters  at  stnng  on  page  222 

a,  a^  string 

aaliew  • 

add  {a^  a^  to  wMxn  ol  each  cnar  whiia 
showing  stnng  ’20 

c.  c„  char  stnng 

wMthahow  - 

add  |c^  to  width  ot  char  while  showing 

stnng  239 

c,  c,  char  a,  a^  stnng 

mWWWWnOm 

comtanad  affects  of  ashow  and 
widthshow  t22 

proc  stnng 

kalww  > 

axacuia  one  between  charactars  shown 
tram  stnng  17$ 

stnng 

atfingwMOi  w, 

width  of  stnng  m  curram  tom  228 

- 

PontOtraetory  dio 

dictionary  ot  fom  dictiotKuias  ’69 

- 

Standardfncading  array 

standard  tom  encoding  vector  226 

Font  cache  operators 

eachaatatua  bsize  omax  msiza  mmax  caize  cmax  etimn 

return  cache  status  and  oarametars  ’26 

w,  w^  II,  II,  ur,  ur, 

aalcachadavtca  - 

declare  cached  character  metrics  2’2 

w,  w, 

swcnwwiuui 

declare  uncached  character  metrics  2’ 3 

num 

aatcacnaHwHt  - 

set  max  oytes  m  cached  character  2’ 3 

Errors 

dlcttuH 

no  more  room  n  dictionary  T46 

dictstackoverflow  too  niany  oegms 

dictstackundertlow  too  many  eras  '<*7 

esecstackoveftlow  exec  nesting  'oo  oeeo  ’S3 

ftandlecrror  called  to  I’eoon  error  information  ‘57 
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interrupt 

e»te"'ai  nteffuct  'eauest  9  g 
control -Cl  '"’ll 

invalidacceu 

attamot  to  vioiata  access  annouta  1  ra 

invalidpiit 

emt  not  'O  looo  '  ’5 

invaiMfllMeeaM 

unaccaotaoia  access  stnng  r  75 

invaiMfont 

mvaiio  font  name  or  diet  '  75 

inva«Mraatora 

improper  restore  >  75 

ioarror 

input  output  error  occurred  1 76 

limttcnaek 

implementation  limit  exceeded  18O 

nocurrantpoinl 

currant  po-^t  is  undefined  ^88 

rangaetwek 

operand  out  of  bounds  197 

staekovarflew 

operand  stack  overitow  22* 

staefcundarftow 

operand  stack  unoerttow  225 

syntaxarror 

syntax  error  m  PostScsiPf  program 
text  230 

Umaout 

tima  limit  excaadad  231 

typadtack 

oparand  of  wrong  typa  235 

uodafinad 

nama  not  known  235 

undaflnadfHanama 

(ila  not  found  236 

urMaflnadraauM 

ovar/undarflow  or  meanmgiass  result  236 

unfliatelMdinarti  • 

expacted  mark  not  on  stack  236 

unraglatarad 

intamai  errtx  236 

VMarrer 

VM  exhaustad  237 
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arc  X  y  r  ang.  arc  - 


sacond 

endpoint 


a  cou^te^clockw(^<;  arc  of  a  circle  to  the  current  path.  pO'>ipl\ 
preceUeU  by  a  itraight  line  >egment.  The  arc  has  1 1.  m  a^  center,  >  ac 
radius,  u^n!^  the  angle  of  a  vector  from  ( v.  m  of  length  »  to  the  tirst 
endpoint  of  (he  arc.  and  o/tg,  the  angle  of  a  vector  from  i.v.  y  i  of  length 
/  to  the  second  endpoint  of  the  arc. 

If  there  is  a  current  point,  the  arc  operator  includes  a  straight  line 
segment  from  the  current  point  to  the  first  endpoint  of  this  arc  and  then 
adds  (he  arc  itself  into  the  current  path.  If  the  current  path  is  empty .  the 
arc  operator  does  not  produce  the  initial  straight  line  segment.  In  any 
event,  the  second  endpoint  of  the  arc  becomes  the  new  current  point. 

Angles  are  measured  in  degrees  counterclockwise  from  the  positive 
t-axis  of  the  current  user  coordinate  system.  The  curve  produced  is 
circular  in  user  space.  If  user  space  is  scaled  non-uniformly  (i.e..  dif¬ 
ferently  in  T  and  >  ).  arc  will  produce  elliptical  curves  on  the  output 
device. 


« 


The  operators  (hat  produce  arcs  (arc.  aren.  and  arcto)  represent  them 
internally  as  one  or  more  Bezier  cubic  curves  (see  curveto)  that  ap¬ 
proximate  the  required  shape.  This  is  done  with  sufficient  accuracy  that 
a  faithful  rendition  of  an  arc  is  produced.  However,  a  program  that 
reads  the  constructed  path  (using  pathforall)  will  encounter  curveto 
segments  where  arcs  were  specified  originally. 

EXAMP(.S; 

newpath  0  0  movoto  0  0  1  0  45  arc  closopath 
This  constructs  a  unit  radius  45  degree  pie  slice'. 

ERRORS: 

limitcheck,  rangecheck.  stackundcrflow.  typccheck 

SEE  ALSO: 

aren.  arcto.  curveto 


arc  i  arc 
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arcn  x  y  /■  arg.  apg,  arcn  - 

larc  ncaativei  hehavcN  like  arc.  but  arcn  huild>  it'  arc  'ecme.nt  n  a 
ciockvwise  direction  im  user  space  i. 


EXAMPLE: 

newoatn  0  0  2  0  90  arc  0  0  i  90  0  arcn  dosepatn 

This  constructs  a  2  unit  radius.  1  unit  aide.  dO  degree  amdshield 
aiperswath'. 

EPRORS: 

limitcheck.  rangechcck.  stackunderflow,  tvpecheck 

SEE  ALSO; 

arc.  arcto,  curveto 


1 1 8  arcn  |  arcn 
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y»  *t,  yt. 


0.4  V4 


X.  y.  X,  y.  r  arctO  xt.  yt.  xt,  yt, 

-ippciiijN  jn  arc  i>l  a  co  ihtf  ..urrcrK  paih.  pcN^iPl'.  pr^tjacj 

'trai^ht  line  'Cj’meni.  The  arc  i'  JefineJ  ►’>  a  raciiii'  .jkI  i'a.' 
line'.  The  langenc  lines  are  ihnse  Jrawn  rrum  ihc  current  point,  nere 
calleti  n,,.  \„i.  to  U|.  1,1  and  (rom  i  v  \ ,  i  to  1 1,.  \  ~i.  i  It  the  current 

point  is  undefined,  arcto  executes  the  error  nocurrentpoint.  i 

The  center  of  the  arc  is  located  \Mthin  the  inner  angle  between  the 
tangent  lines;  it  is  the  onl\  point  located  at  distance  r  m  a  direction 
perpendicular  to  both  lines.  The  arc  begins  at  the  first  tangent  point 
ut,.  on  the  first  tangent  line,  passes  between  its  center  and  the 
point  i.\,.  1 1 1.  and  ends  at  the  second  tangent  point  i  ir..  ir.i  on  the 
second  tangent  line. 

Before  constructing  the  arc.  arcto  adds  a  straight  line  segment  from  the 
current  point  i  \„.  >,,)  to  ia/,.  yr|).  unless  those  points  are  the  same.  In 
any  event.  ( i/,.  vrd  becomes  the  new  current  point. 

The  curve  produced  is  circular  in  user  space.  If  user  space  is  scaled 
non-uniformiy  ii.e..  differently  in  v  and  vi.  arcto  will  produce  elliptical 
curves  on  the  output  device. 

If  the  two  tangent  lines  are  collinear.  arcto  merely  appends  a  straight 
line  segment  from  i.Vn.  to  i.v,.  > , ),  considenng  the  arc  to  be  part  of  a 
degenerate  circle  (with  radius  0)  at  that  point. 

The  values  returned  by  arcto  are  for  information  only,  they  are  the  two 
tangent  points  in  user  space. 

EXAMPLE; 

newpath  0  0  moveto 
G  4  4  4  1  arcto 
4  {pop}  repeat 
4  4  iineto 

This  constructs  a  4  unit  wide,  d  unit  high  right  angle  with  a  1  unit 
radius  rounded  comer. 

ERRORS: 

limilcheck.  nocurrentpoint.  stackunderflow.  typecheck. 
undefinedresult 

SEE  AcSO: 

arc.  arcn.  curveto 


arcto  arcto 
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clip  -  clip  - 

intersects  the  inside  of  the  current  clipping  path  \Mth  the  inside  of  the 
current  path,  to  produce  a  ne\fc  ismallen  current  clipping  patn  The 
inside  of  the  current  path  is  determined  b>  the  normal  PtosTScRipr 
non-zero  v^inding  number  rule  isee  section  -1.61.  vwhile  the  inside  of  the 
current  clipping  path  is  determined  by  whatever  rule  was  used  at  the 
time  that  path  was  created.  Before  computing  the  intersection,  the  clip 
operator  implicitly  closes  any  open  subpaths  of  the  current  path. 

In  general,  clip  produces  a  new  path  whose  inside  (according  to  the 
non-zero  winding  number  rule)  consists  of  all  areas  that  are  inside  both 
of  the  onginal  paths.  The  manner  in  which  this  new  path  is  constructed 
(order  of  its  segments,  whether  or  not  it  self-intersects.  etc.)  is  not 
specified. 

There  is  no  way  to  enlarge  the  current  clipping  path  (other  than  by 
initciip  or  initgraphicsi  or  to  set  a  new  path  without  refereiKe  to  the 
current  one.  The  recommended  way  of  using  dip  is  to  bracket  the  clip 
and  the  sequence  of  graphics  to  be  clipped  with  gsave  and  grestore. 
The  grestore  will  restore  the  clipping  path  that  was  in  effiect  before  the 
gsave. 

Unlike  fill  and  stroke,  clip  does  not  implicitly  perform  a  newpath  after 
It  has  finished  using  the  current  path.  Any  subsequent  path  construction 
operators  will  append  to  the  current  path  unless  newpath  is  executed 
explicitly.  This  can  be  a  source  of  unexpected  behavior. 

ERRORS: 

limitchcck 

SEE  ALSO; 

eoclip,  clippath.  initciip 


128  clip  I  clip 
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ctosapath  -  ctoscpath  - 

..li'Ne'  [he  current  'uhpath  hv  appenJine  a  'trai^hi  me  ,  n 

nectina  the  curreni  piJini  iCy  the  Nubpath  '  'tanine  point  eeneraiis  '.ne 
point  moM  recentl>  'pecified  b>  movetoi.  It  the  eurrent  'ubpath  u 
alread>  closed  or  the  current  path  is  empt>.  closepath  does  nothing. 
I  See  section  4.5.) 

closepath  terrutnates  the  current  subpath.  .Appending  another  segment 
to  the  current  path  vmII  begin  a  new  subpath,  even  it  it  is  drawn  from 
the  endpoint  reached  by  the  closepath. 

ERRORS: 

limitchcck 

SEE  ALSO; 

nil.  stroke 


130  clOMpath  I  eoncattnatrix 
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curvcto  X.  y.  *3  ^2  *i  curv«to  - 


add'  a  Be/ier  cubic  section  to  the  current  path  bet\'-een  the  current 
point,  referred  to  here  as  ii^.  >„).  and  the  point  i  v,.  v,i.  using  (  i|.  1 

and  iv,.  v,i  as  the  Bezier  cubic  control  points  After  constructing  the 
curve,  curveto  makes  i.t^  become  the  new  current  point.  If  the 
current  pome  is  undefined  1  because  the  current  path  is  empts  1.  curveto 
executes  the  error  nocurrentpoint. 

The  four  points  define  the  shape  of  the  curve  geomemcally  The  curve 
Stans  at  i.r^.  y^).  it  is  tangent  to  the  line  from  l.r^.  Vq)  to  (.c, .  > , )  at  that 
point,  and  it  leaves  the  point  in  that  direction.  The  curve  ends  at 
i.rj.  >;).  It  IS  tangent  to  the  line  from  l.r^.  ys)  to  i.Cj.  Vj)  at  that  point,  and 
it  approaches  the  point  from  that  direction.  The  lengths  of  the  lines 
l.rg.  to  (  r,.  y,)  and  l.r,.  y,)  to  (.tj.  Vj)  represent  in  some  sense  the 
velocity'  of  the  path  at  the  endpoints.  The  curve  is  always  entirely 
enclosed  by  the  convex  quadrilateral  defined  by  the  four  points. 


The  mathematical  formulation  of  a  Bdzier  cubic  curve  is  derived  from  a 
pair  of  parametric  cubic  equations; 

nr)  sr  *c^-*-  Xq 

y(  f )  »  b^t^  *  cj  *  Vq 

The  cubic  section  produced  by  enrveto  is  the  path  traced  by  tin  and 
yin  as  r  ranges  from  0  to  1.  The  EIdzier  control  pointt  corresponding  to 
this  curve  are; ' 


.r(S.to  +  c^3  y,  *yo>c/3 

.r,  3  .t,  (c,  f  b,)/3  y,  3  y,  (c^  -i-  b,)/3 

t]  3  tg  ^c,*b,*a^  yj  *  >0  ♦  b^  4. 

ERRORS; 

limitchcck,  nocurrentpoint.  stackunderflow,  typecheck 

SEE  ALSO; 

llncto.  moveto,  arc.  aren.  arcto 


For  3  more  thorough  ireaimem  of  the  maihemaiics  of  Bezier  cubics.  ■see 
J  D.  Foley  and  A.  Van  0am.  Fundamentals  of  Interactive  Computer  Graphics. 
Addison-Wesley.  1982. 


140  curveto  i  eurveto 
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mov«to  x  y  mov«to  - 


^ta^s  a  nev*  Nubpath  or  the  turrent  path,  moveto  'ets  the  current  point 
m  the  graphics  state  to  the  user  space  coordinate  i  r.  1 1  without  adding 
any  line  segments  to  the  current  path. 

If  the  previous  path  operation  in  the  current  path  was  also  a  moveto  lor 
rmovetoi.  that  point  is  deleted  from  the  current  path  and  the  new 
moveto  point  replaces  it. 

ERROnS; 

limitchcck.  stackunderflow,  typccheck 
SEE  ALSO: 

rmoveto,  lineto.  oirveto.  arc,  closepatb 


186  moveto  |  no 
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reurvato  dx,  dy,  dxj  dyj  dx,  dy,  reurvato  - 

(relative  curvetoi  adds  a  Bezier  cubic  section  to  the  current  path  in  the 
same  manner  as  curveto:  however,  the  three  number  pairs  are  inter¬ 
preted  as  displacements  relative  to  the  current  point  i.tf,.  Vq)  rather  than 
as  absolute  coordinates.  That  is.  rcurvcto  constructs  a  curve  from 
(to-  >0^  vo+dvj).  using  (.tQ+dr,.  Vo+dv,)  and 

*  (.tQ-nirj,  vq-k/v,)  as  ^zier  control  points.  S«  the  descnption  of 

curveto  for  complete  information. 

ERRORS: 

limitctMck.  nocurrcntpoint.  sucKunderflow,  typcciicck. 
undcfliMdrcsult 

SEE  ALSO: 

curveto.  rtineto.  rnraveto 


198  rcHeek  I  read 
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rtineto  dx  dy  riincto  - 


I  relative  Imetoi  appends  a  vtraiitht  line  vegmeni  to  the  current  path  ;n 
the  same  manner  as  iineto:  however,  the  number  pair  is  interpreted  as  a 
displacement  relative  to  the  current  point  i.v.  vi  rather  than  as  an  ab¬ 
solute  coordinate.  That  ts.  riineto  constructs  a  line  from  i  r.  v  >  to 
t.<c*dx.  v-k/v)  and  makes  i.rs^r.  >-rd>  )  be  the  new  current  point. 

iimitcheck.  nocurrentpoinl.  stackunderflow,  typcchcck 

SEE  ALSO: 

Iineto.  rmoveto.  rcurveto 

rmovdto  dx  dy  rmovoto  - 

(relative  moveto)  starts  a  new  subpaih  of  the  current  path  in  the  same 
maiuier  as  moveto:  however,  the  number  pair  is  interpreted  as  a  dis¬ 
placement  relative  to  the  current  point  (x,  v)  rather  than  as  an  absolute 
coordinate.  That  is.  rmoveto  makes  (x-fdx.  y>dy)  be  the  new  current 
point,  without  coniwcttng  it  u>  the  previous  poinL  If  the  current  point  is 
undefined  (because  the  current  path  is  empty),  rmoveto  executes  the 
^  error  operator  nocurrentpoiaL 

ERRORS: 

Hmitcheck.  aocurmtpoiat,  stackundcrflow,  typcchcdt 
SEE  ALSO: 

moveto,  riineto,  rcurveto 


204  riineto  |  rmoveto 
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Strok*  -  Strok*  - 


4 


strokopath 


paints  a  line  follov^mg  the  current  path  and  using  the  current  color  Tht> 
line  IS  centered  on  the  path,  has  sides  parallel  to  the  path  >egments.  and 
has  a  width  (thickness)  given  by  the  current  line  width  parameter  in  the 
graphics  state  (see  setlincwidth).  stroke  paints  the  joints  between  con¬ 
nected  path  segments  with  the  current  line  Join  (see  setlincjoini  and  the 
ends  of  open  subpaths  with  the  current  line  cap  (see  setlinccapi.  The 
line  is  either  solid  or  broken  according  to  the  dash  pattern  esublished 
by  sctdash. 

The  parameters  in  the  graphics  sute  controlling  line  rendition  (line 
width,  line  join,  and  so  forth)  ate  consulted  at  the  time  stroke  is  ex¬ 
ecuted:  their  values  dunng  the  time  the  path  is  being  constructed  are 
irrelevant. 

If  a  subpath  is  degenerate  (consists  of  a  single  point),  stroke  paints  it 
only  if  round  line  caps  have  been  specified,  pi^ucing  a  filled  circle 
centered  at  that  point  If  bun  or  projecting  square  line  caps  have  been 
specified,  stroke  produces  no  output  since  the  oriemation  of  the  caps 
would  be  indeterminate. 

stroke  implicitly  performs  a  ncwpath  after  it  has  finished  painting  the 
current  path.  To  preserve  the  current  path  across  a  stroke  operation,  use 
the  sequence:  gsave  stroke  grcstor*. 

SRROflS: 

limitcheck 

SEE  ALSO: 

sctlincwidth.  setlincjoia,  setmiterlimit  setlinccap,  sctdash 


-  strokapath  - 

replaces  the  current  path  with  one  enclosing  the  shape  that  would  result 
if  the  stroke  operator  were  applied  to  the  current  path.  The  path  result¬ 
ing  from  strokcpath  is  suiuble  as  the  implicit  operand  to  nil.  clip,  or 
pathbboa.  In  general,  this  path  is  not  suiuble  for  stroke,  as  it  may 
contain  intenor  segments  or  disconnected  subpaths  produced  by 
strokcpath  s  stroke  to  outline  conversion  process. 

ERRORS: 

limitcheck 

SEE  ALSO: 

nil.  clip,  stroke,  pathbbox.  charpath 


stroka  |  strokapatn  229 
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Mtflat 


num  Mtflat  - 

^ets  the  rlatne^^  parameter  in  the  current  graphics  Ntate  so 
must  be  a  positive  number.  This  controls  the  accuracv  with  whicn 
curved  path  segments  are  to  be  rendered  on  the  raster  output  dev  ice  bv 
the  stroke,  fill,  and  clip  operators.  Those  operators  render  curves  bv 
approximating  them  with  a  senes  of  straight  line  segments.  Flatness  is 
an  informal  term  for  the  error  tolerance  of  this  approximation:  it  is  the 
maximum  distance  of  any  point  of  the  approximation  from  the  cor¬ 
responding  point  on  the  true  curve,  measured  in  output  device  pixels. 

The  choice  of  flatness  value  is  a  tradeoff  between  accuracy  and  execu¬ 
tion  efficiency.  Very  small  values  (less  than  1  device  pixel)  produce 
very  accurate  curves  at  high  cost,  since  enormous  numbers  of  tiny  line 
segments  must  be  produced.  Larger  values  produce  cruder  appro.' ima- 
tions  with  substantially  less  computation.  A  default  value  of  the  flat¬ 
ness  parameter  is  established  by  the  device  setup  routine  for  each  raster 
output  device:  this  value  is  based  on  characteristics  of  that  device  and  is 
the  one  suiuble  for  most  applications. 

ERRORS: 

stackundcrflow,  typcchcck 
SEE  ALSO; 

currcntfUt.  fUtttcapath,  stroke,  fill 


MfflM  I  satfont  215 
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PostScript  Image  Capabilities 


219 


image  vvidtn  heignt  oit&sampie  matrix  proc  imag*  - 

renders  a  sampled  image  onto  the  current  page.  The  descnption  here 
only  summarizes  the  image  operator;  see  section  -»  '  for  full  details 

The  sampled  image  is  a  rectangular  array  of  H/dr/i  x  height  sample 
values,  each  of  which  consists  of  bitsi sample  bits  of  dau  1 1.  2.  4.  or  8). 
The  dau  is  received  as  a  sequence  of  characten.  i.e..  8-bit  integers  in 
the  range  0  tc  255.  if  biisisample  is  less  than  8.  sample  values  are 
packed  left  to  right  within  a  character  (but  see  the  note  in  section  4.7). 

The  image  is  considered  to  exist  in  its  own  coordinate  system.  The 
rectangular  boundary  of  the  image  has  its  lower  left  comer  at  lO.  0)  and 
its  upper  nght  comer  at  {width,  height).  The  matrix  operand  specifies  a 
transformation  from  user  space  to  the  image  coordinate  system. 

image  executes  proc  repeatedly  to  obtain  the  actual  image  dau.  proc 
must  return  (on  the  operand  suck)  a  string  conuimng  any  number  of 
additional  characters  of  sample  data.  (If  proc  returns  a  string  of  length 
zero,  image  will  terminate  execution  prematurely.)  The  sample  values 
are  assumed  to  be  received  in  a  fixed  order  (0. 0)  through  (width- 1 . 0). 
then  (0. 1)  through  (widrh-l.  1).  etc. 

Use  of  the  image  operator  after  a  setcachedevice  within  the  context  c' 
a  BuUdChar  procedure  is  not  permitted  (an  undefliicd  error  results); 
*  however,  use  of  imagemaak  in  that  context  is  permitted  (see  the 
setcachedevice  operator  and  section  5.7). 


EXAMPLE: 

/picstr  256  string  daf  %  string  to  hold  imago  data 

45  140  translaM  %  locata  lower  left  comer  of  image 

132  132  scale  %  map  image  to  132  pomt  square 

256  256  6  %  dimensions  of  source  image 

[256  0  0  -256  0  256]  map  unit  square  to  source 

(currentfile  %  read  image  dau  from  program  file 

picstr  readhexstnng  pop) 
image 

4c47494(}4d4c524c4d5053505l554c5lS2  ... 

S959565cS  ...  (131072  Max  digits  of  imarc  uata) 

ERRORS; 

stackundcrflow,  typecheck.  undefinedresult.  undefined 


SEE  ALSO: 

imagcmask 
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imagtmask 


^latn  neiqrt  nverr  .-natf''  oroc  tmagamask  - 


IS  similar  to  the  image  operator:  however,  it  treats  the  source  image  as 
a  mask  of  1  bit  samples  that  are  u>ed  to  control  v^here  to  appK  ^amt 
I  with  tne  current  colon  and  where  not  to  See  the  Je>cnp[ion  u  tne 
image  operator  and  the  presentation  ot  sampled  images  in  section  4  ' 

imagemask  uses  the  width,  height,  matrix,  and  proc  operands  in 
precisely  the  same  way  as  image.  The  invert  operand  is  a  boolean  that 
determines  the  polanty  of  the  mask.  If  invert  is  false,  portions  of  the 
image  corresponding  to  source  sample  values  of  0  are  painted,  while 
those  corresponding  to  sample  values  of  1  are  left  unchanged.  If  invert 
IS  true,  sample  values  of  1  are  painted  and  sample  values  of  0  are  left 
unchanged. 

imagemask  is  most  useful  for  printing  characters  represented  as  bit¬ 
maps.  Such  bitmaps  represent  masks  through  which  a  color  is  to  be 
transferred:  the  bitmaps  themselves  do  not  have  a  color  (see  secuon 
4.7). 


EXAMPLE: 

45  228  translate 
132  132  scale 


%  locate  lower  left  comer  of  square 
%  scale  1  unit  to  1 32  points 


0  0  moveto  0  1  lineto  %  fill  square  with  gray  backgrounq 

1  1  lineto  1  0  lineto  dosepath 
.9  setgray  fill 


0  setgray 
24  23 


%  paint  mask  black 
%  dimensions  of  source  mask 


true  %  oaim  the  l  bits 

[24  0  0  -23  0  23]  %  map  unit  square  to  mask 

{<003800  002700  002480  OE4940  114920 
148220  3C8650  75FE88  l7F?aC  175F14 
1C07E2  3803C4  703182  F8EDFC  B2B8C2 
BB6F84  31BFC2  18EA3C  OE3EOO  07FC0O 


03F800  1  El 800  lFF800>}  %  mask  data 


imagemask 


ERHORS: 

stackunderflow,  typecheck.  undeflnedresult 

SEE  ALSO: 

image 


Imagemask  |  imagamsak  1 71 
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APPENDIX  3 


IGES  ENTITIES  AS  RENOESEO  BY  GRAPHICS  STANDARDS  SYSTEM 


This  Appsndix  dsscribss  «ach  of  th*  IGES  srititios  in  turn,  noting 
how  wall  thass  antitias  could  ba  randarad  by  a  systam  basad  upon 
tha  graphics  standards. 


1.  Gaoaatrie  Entltias 

CIRCULAR  ARC.  Not  availabla  in  GKS/PHIGS.  Prasant  as  CIRCLE  and 
3 "POINT  ARC  in  CGI/CGM. 

COMPOSITE  CURVE.  Randarad  by  POLYLINE  in  GKS/PHIGS;  by  POLYLINE, 
ARC,  and  ELLIPTICAL  ARC  in  CGI/CGM.  Tha  full  conics  and  splinas 
of  IGES  ara  not  diractly  supportad,  but  would  hava  to  ba 
approxiaatad  by  POLYLINE. 

CONIC  ARC.  Not  availabla  in  GXS/PHIGS.  Prasant  as  CIRCLE, 
ELLIPSE,  3 -POINT  ARC,  and  ELLIPTICAL  ARC  in  CGI/CGM.  Parabolas 
and  hyparbolaa  ara  not  diractly  supportad. 

COPIUS  DATA.  Diractly  availabla  as  POLYLINE  with  diffarant  lina 
typas. 

PLANE.  Unboundad  planas  naad  no  diract  visualization.  Boundad 
planas  eorraspond  to  POLYGON  SET  in  GXS/PHIGS/CGM  and  ara 
supplaaantad  by  CLOSED  FIGURE  in  CGI. 

LINE.  Availabla  as  a  two-point  POLYLINE. 

PARAMETRIC  SPLINE.  Can  ba  visualizad  by  linas,  arcs,  ate. 
Howavar,  information  about  tha  shapa  is  lost. 

PARAMETRIC  SPLINE  SURFACE.  Can  ba  visualizad  by  ractanglas, 
linas,  arcs,  ate.  Howavar,  information  about  tha  shapa  is  lost. 

POINT.  Availabla  as  POLYMARKERS  for  pra-dafinad  symbols  and 
positionad  SEGMENTS  (GKS/CGI  but  not  COM)  or  STRUCTURES  (PHIGS) 
for  usar-dafinad  symbols. 

RULED  SURFACE.  Can  ba  visualizad  by  linas,  ate.  Howavar, 
information  about  tha  shapa  is  lost. 

SURFACE  OF  REVOLUTION.  Can  ba  visualizad  by  li.nas,  arcs,  etc. 
Howavar,  information  about  tha  shapa  is  lost. 
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TABULATED  CYLINDER.  Can  ba  visualized  by  lir.es,  arcs,  etc. 
H:-.-.evar,  inrorrtabion  about  the  shape  is  lost. 


TRANSFORMATION  MATRIX.  Really  used  lilce  an  attribute  in  ICES. 
Also  special  fom  numbers  are  used  with  certain  contructs  Icr 
"•.r.ita  Elerent  Analysis  and  viewinq.  Closely  related  to  3ECve::t 
TP.A.VSrCRlLATICN'S  of  GK3  and  PHIGS  transformation  matrix  structure 
elements  used  for  nodellinq  and  viewing.  No  direct  parallel  in 
CGI  or  CGM. 

FLASH  ENTITY.  In  GKS,  only  have  POLYMARKER  or  segments  to 
realize  t.he  forma.  In  CGX/CCM,  you  also  have  CIRCLE  and 
RECTANGLE.  IGES  flash  entity  form  4,  rounded  rectangle,  is  not 
directly  available  in  any  of  the  graphics  standards. 

RATIONAL  B-SPL2NE  CURVE.  Can  bs  visualized  by  lines,  arcs,  etc. 
However,  information  about  the  shape  is  lost.  Parabolas  and 
hyperbolas  not  directly  supported  by  the  graphics  standards. 

RATIONAL  B-SPLINE  SXntPACE.  Can  be  visualized  by  lines,  arcs, 
etc.  However,  information  about  the  shape  is  lost.  Parabolas 
and  hyperbolas  not  directly  supported  by  the  graphics  standards. 

OFFSET  CURVE.  Can  be  visualized  by  lines,  ares,  etc.  However, 
information  *  about  the  relationship  between  the  two  entities  is 
lost. 

CONNECT  POINT.  Can  be  visualized  by  lines.  However,  information 
about  the  relationship  between  the  entities  is  lost. 

NODE.  Not  directly  visualized,  so  no  need  for  support  from  the 
graphics  standards.  However,  not  unlike  a  PHIGS  structure  label. 


FINITE  ELEMENT.  Thirty-three  topologies  are  currently  defined  by 
IGES  version  3.  All  can  be  visualized  using  the  graphics 
primitives  of  line,  arc,  ellipse,  etc.,  with  loss  of  information 
concerning  the  relationships  between  the  lines  and  curves  making 
up  the  wire-frame  model.  Furthermore,  the  IGES  specification  is 
much  more  compact. 

NODAL  DISPLACEMENT  AND  ROTATION.  These  are  attributes  that  are 
used  to  communicate  finite  element  post  processing  data. 

OFFSET  SURFACE.  Can  be  visualized  by  lines,  arcs,  etc. 

However,  information  about  the  relationship  between  the  two 
entities  is  lost. 

CURVE  ON  PARAMETRIC  SURFACE.  Can  be  visualized  by  lines,  arcs, 
etc.  However,  information  about  the  relationship  becwae.’i  t.ne 
ourve  and  the  surface  is  lost. 
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TRIMMED  (PARAMETRIC)  SURFACE.  Can  be  visualicsd  by  l-.-.es,  arcs, 
acc.  Hovev»r.  ir.Icrratiaa  about  tbe  ralatior.sbics  arcr.q  t.-.e 
boundary  lines  and  other  curved  lines  used  to  represent  tne 
surface  is  lost. 

ANGULAR  DIMENSION.  Visualize  using  text,  lines,  arrovs,  ar.d 
arcs.  Cnly  arrows  not  directly  supported  in  the  gracn.cs 
standards.  See  discussion  under  LEADER  entity  below. 

CENTERLINE.  Use  graphics  circles  (in  CGI/CGM)  only  and  special 
line  types.  Could  be  made  available  in  GKS/PHIGS  through  special 
marker  types. 

DIAMETER.  Visualize  using  text,  lines,  arrows,  and  arcs. 

FLAG  NOTE.  Visualize  using  text  and  fill  area  (polygon) 
priaitives. 

GENERAL  lABEL.  Visualize  using  text,  lines,  and  arrows. 

GENERAL  NOTE.  A  general  note  entity  consists  of  one  or  more  text 
strings.  Each  text  string  contains  text,  a  starting  point,  text 
size,  and  angle  of  rotation  of  the  text.  A  single  font  number 
applies  to  the  whole  note  and  incorporates  the  separate  concepts 
of  type  face  appearance  of  the  characters;  e.g.,  bold  Helvetica, 
italic  Futura)  and  character  set  (shape  of  the  characters;  e.g., 
ASCII,  German  National  Set,  Math,  Greek).  Only  7-bit  character 
codes  are  supported.  In  addition,  a  form  number  is  used  to 
desi^ate  the  layout  of  the  (possibly  multiple)  text  strings,  the 
justification  of  the  strings  within  a  text  rectangle,  and  whether 
there  are  subscripts,  superscripts,  fractions,  and  embedded  font 
changes.  The  GKS/PHIGS  TEXT  and  CGI/CGM  TEXT,  APPEND  TEXT,  and 
RESTRICTED  TEXT  primitives  with  their  numerous  text  attributes 
are  capable  of  visualizing  any  general  note  entity.  With 
RESTRICTED  TEXT  and  APPEND  TEXT,  CGI/CGM  are  a  bit  more  capable 
than  GKS/PHIGS. 

LEADER.  Eleven  arrow  head  types  are  specified  in  IGES  version  3. 
Although  all  can  easily  be  rendered  using  more  primitive  lines 
and  polgons,  the  information  chat  the  arrowhead  belongs  with  the 
leader  line  is  lost  when  described  using  graphics  standards 
primitives. 

LINEAR  DIMENSION.  Visualized  using  text,  lines,  and  arrows. 

ORDINATE  DIMENSION.  Visualized  using  text,  lines,  and  arrows. 

POINT  DIMENSION.  Visualized  using  text,  lines,  arrows,  circles, 
and  polylines/polygons  (hexagons) . 
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RADIUS  DIMENSION.  Visualized  using  text.  Lines,  arrsvs,  and 
arcs. 

SECTION.  Visualized  using  FILL  AREA  with  HATCH  patterns.  Of  t.he 
eight  pre-defined  IGES  patterns,  two  correspond  to  CGI/CGM  hatch 
patterns;  nanely,  IGES  fom  31  is  CGM  hatch  style  3  and  IGES  fern 
37  is  CGM  hatch  style  6. 

GENERAL  SYMBOL.  Visualized  using  text,  lines,  arrows,  etc.,  and 
possibly  grouped  in  SEGMENTS  (GKS  or  CGI  but  not  CGM)  or 
STRUCTURES  (PHIGS). 

SECTIONED  AREA.  Visualized  with  POLYLINE  and  FILL  AREA  in 
GKS/PHIGS/CGM  and  also  using  CLOSED  FIGURE  with  fill  in  CGI. 
However,  the  IGES  representation  is  generally  more  conpact, 
because  there  is  control  over  the  angle  and  spacing  of  the  lines 
that  make  up  the  cross-hatched  fill  pattern.  In  these  eases,  the 
DISJOINT  POLYLINE  element  of  CGI/CGM  may  help.  In  its  default 
state,  IGES  line  pattern  code  l  corresponds  to  CGM  hatch  style  3, 
line  pattern  code  16  to  CGM  hatch  style  6,  and  line  pattern  code 
13  to  CGM  hatch  style  5. 

WITNESS  LINE.  Visualized  using  POLYLINES,  although  the  DISJOINT 
POLYLINE  of  CGI/CGM  may  be  useful  in  certain  special  cases. 

ASSOCIATIVITY  DEFINITION.  Defines  the  relationship  among 
entities.  These  relationships  are  lost  in  CGM,  occasionally  can 
be  represented  by  GXS/CGI  segments,  and  with  somewhat  greater 
likelihood  can  be  represented  by  PHIGS  structures. 

ASSOCIATIVITY  INSTANCE.  Many  predefined  associativity 
relationships  exist  in  IGES.  These  include  simple  and  ordered 
GROUPS  (both  doubly  linked  and  forward-only  linked  entities) , 
external  references  and  external  reference  filths,  labels,  and 
parent-child  structures.  These  have  some  parallels  in  PHIGS 
structures,  but  in  general  need  not  be  directly  handled  by  a 
graphics  viewing  system  like  CGI/GKS.  Likewise,  the  PLANAR  and 
FLOW  instance  types  do  not  require  direct  support  from  the 
graphics  system.  The  VIEWS  VISIBLE  and  VIEWS  VISIBLE,  COLOR, 

LINE  WEIGHT  instance  type  have  an  effect  on  the  visualization  of 
the  IGES  model.  The  necessary  controls  for  proper  visualization 
are  available  in  the  graphics  standards,  using  viewports,  color 
tables,  and  line  width  specification  mode.  Finally,  the 
DIMENSIONED  GEOMETRY  instance  type  has  already  been  discussed  in 
Section  1  above,  under  the  separate  elements  for  A:iGULAR 
DIMENSION,  LINEAR  DIMENSION,  POINT  DIMENSION,  DIAMETER  DIMENSION, 
RADIUS  DI.MENSION,  and  ORDINATE  OI.MENSION. 
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DRAWING.  A  irawi.-.g  is  a  coileccicr.  ai  ar.r.atatian  «r.titi»s  ir.i 
vievs.  Multipla  drawings  can  b«  ir.cludad  in  a  singla  file. 
Drawir.gs  ns^-e  nanas  and  size;  units  nay  =e  specified  far  t.-.-r 
drawing.  A  drawing  closely  corresponds  to  a  CCK  or  to  any  i.tage 
displayed  on  a  graphics  view  surface  by  any  of  t.he  prograncer 
interface  standards:  GKS.  CGI,  or  PHIGS. 

LIME  FONT  DEFINITION.  Two  types  of  line  fsnts  .nay  ce  iefi-.ad. 

One  type  considers  a  line  font  as  a  repetition  of  a  basic  pattern 
of  visible-blanked  segments  superimposed  upon  a  straight  line  or 
a  curve.  The  other  type  considers  a  line  font  as  a  repetition  of 
a  template  figure  that  is  displayed  at  regularly  spaced  locations 
along  a  planar  anchoring  curve.  None  of  the  graphics  standards, 
at  present,  support  user-defined  line  types;  the  type  I 
capability  would  have  to  be  visualized  by  POLVLIN'E  (in  GKS/PHIGS) 
and  DISJOINT  POLyLI.'JE  (in  CGI/CCM)  ;  the  type  two  capability  by 
using  segments  or  structures  in  PHIGS/GXS/CCI  and  only  lines, 
rectangles,  etc.  in  CGM. 

HAC3tO  Capability.  This  facility  allows  the  IGES  specification  to 
be  extended  beyond  the  common  entity  subset,  utilizing  a  formal 
mechanism  which  is  a  part  of  the  IGES  Specification.  This 
facility  is  available  in  an  extremely  limited  fashion  in  the 
graphics  standards  as  ESCAPE  and  GENERALIZED  DRAWING  PRIMITIVE 
(GOP) .  ^ 

PROPERTY.  This  facility  is  available  in  the  graphics  standards 
as  APPLICATION  DATA  and  MESSAGE.  Many  engineering  specific 
properties  are  defined  in  the  ICES  specification.  A  few  of  them 
correspond  to  graphics  elements,  generally  useful  for  rendering  a 
picture.  These  are  Region  Restriction,  Hierarchy  (partial) , 

Name,  Drawing  Size  and  Drawing  Units. 

SUBFZGORE  Definition.  All  such  relationships  can  be  visualized 
fairly  straightforwardly  using  PHIGS  structures,  somewhat  more 
difficultly  using  GKS  and  CGI  segments,  and  much  more  difficultly 
in  CGM. 

TEAT  FONT  Definition.  This  IGES  facility  provides  for  the 
exchange  of  font  definitions,  which  are  limited  to  a  model  of 
the  motion  of  an  imaginary  pen  moving  between  t.he  points  of  an 
integer  Cartesian  "font  coordinate  system."  None  of  the  graphics 
standards  provide  support  for  "user-defined"  fonts.  However, 
such  a  strolce-precision  text  capability  can  easily  be  built  on 
top  of  all  the  graphics  standards.  Compactness  of 
representation  is  lost,  but  spaed  of  picture  generation  should 
not  be  much  worse. 
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VIEW  ENTITY.  TMs  ICES  •nticy  d«fin«s  a  frasaworlc  fcr  spacifying 
a  viawir.g  sriar.cation  of  an  objact  in  thraa  dir.ansisr.al  aodei 
space,  tn* 'frasaworlc  is  also  usad  co  supporr  cha  pro^accion  of 
all  or  part  of  aodal  space  onto  a  view  plana.  Ona  type  of 
projection,  an  orthographic  parallel  projection,  can  be 
specified.  Clipping  to  a  view  volune  is  supported. 

The  3-D  graphics  standards,  GKS-3D  and  PHICS,  have  a  such  richer 
viewing  model.  They  allow  a  full  4x4  transformation  matrix  co  be 
used,  thus  obtaining  perspective  projections  and  various  oblique 
parallel  projections  as  well. 

EXTERNAL  REFERENCE  ENTITY.  PKXGS  Archive  Files  would  directly 
support  this  element.  The  other  standards  (GXS/CGI/CGM)  would 
have  to  do  a  lot  more  processing  to  directly  support  this 
feature. 

NODAL  LOAO/CONSTRAINT  ENTITY.  A  special  element  to  support 
Finite  Element  Modelling. 

COLOR  DEFINITION  ENTITY.  Not  directly  available  in  GKS/PHIGS, 
but  is  present  in  CGI/CGM  as  the  MAXIMUM  COLOR  EXTENT  element. 

In  GKS/PHIGS,  the  application  would  query  the  worlcstation 
description  tables  to  gather  sufficient  information  to  adjust  for 
this  entity  before  rendering  the  picture  with  a  graphics  system. 

TEXT  DISPLAY  ENTITY.  See  the  earlier  discussion  under  the  ICES 
GENERAL  NOTE  ENTITY.  The  attributes  Of  text  include  height  and 
width,  font  index,  slant  angle,  rotation  angle,  mirror  flag,  and 
horizontal/vertical  text  path.  All  such  entities  can  be 
correctly  displayed  by  a  proper  setting  of  the  graphics  standards 
text  attributes,  which  are  common  to  PHXGS/CXS/ CGI/CGM. 
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IGES  Text  Capabilities 


231 


310  -  TEXT  FONT  DEFINITION 


<».}.10  Text  Font  0«finition  Entity. 

This  entity  defines  the  appearsnee  of  characters  in  a  text  font.  The 
data  describing  the  appearance  of  a  character  may  be  located  by  the 
Font  Code  (FC)  and  the  ASCII  character  code.  This  entity  may  describe 
any  or  all  the  characters  in  a  character  set.  Thus,  this  entity  may  be 
voed  to  deaeribe  a  complete  font  or  a  modification  to  a  subset  of 
characters  in  another  font.  Font  Ntxnber  and  Font  Name  are  the 
number  and  name  used  to  reference  the  font  on  the  originating  system. 
When  this  entity  is  a  modflcation  to  another  font,  the  Supersedes  Font 
value  (Parameter  3)  indicates  which  font  the  entity  motf fies.  This 
value  is  an  integer  which  indicates  the  font  number  to  be  modfied  or 
the  negative  of  the  pointer  value  to  the  directory  attry  of  another  text 
font  definition  entity.  When  this  entity  medfies  another  font*  Ue., 
Parameter  3  references  another  font,  the  definltienB  in  this  entity 
supersede  the  definition  in  the  original  font.  For  example,  a  complete 
set  of  characters  may  have  their  font  definition  specified  by  this  entity. 
Another  text  font  definition  entity  could  reference  the  first  definition 
and  modify  a  subset  of  the  characters. 

Each  character  is  defined  by  overlaying  an  equally  spaced  square  grid 
ever  the  character.  The  character  is  decomposed  into  straight  line 
segments  which  connect  ^d  poinis.  Grid  points  are  referenced  by 
standard  Cartesiaif  coerdiriatas.  The  position  of  the  character  relative 
to  the  grid  is  defined  by  two  points.  The  character's  origin  point  is 
placed  at  the  origin  (0,0)  of  the  grid  and  defines  the  position  of  the 
character  relative  to  the  text  origin  of  that  character.  The  second 
point  defines  the  origin  point  of  the  character  following  the  character 
being  defined.  This  allows  the  spacing  between  characters  to  be 
specified.  Construction  of  text  strings  consists  of  placing  the  character 
origin  of  the  first  character  at  the  text  string  origin  and  placing 
subsequent  character  origins  at  the  location  specified  in  the  previous 
character  as  the  location  of  the  next  character's  origin. 
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The  pvamcterizetion  of  the  character  appearance  is  described  by  the 
motion  of  an  imaginary  pen  moving  between  grid  points.  Commands  to 
move  the  pen  reference  the  grid  location  to  which  the  pen  is  to  move. 
The  pen  may  be  "lilted  such  that  its  movement  is  not  displayed.  The 
representation  of  the  movement  of  the  pen  is  a  sequence  of  pen 
commands  and  grid  locations.  Each  movement  of  the  pen  is  represented 
by  a  pen  updown  flag  and  a  pair  of  integer  grid  coordinates.  The  pen 
up/down  flag  defaults  to  pen  down.  A  flag  value  of  1  means  the  pen  is 
to  be  lifted  G.e.,  display  off)  and  moved  to  the  next  location  in  the 
sequertce.  Upon  arrival  at  this  location  the  pen  is  returned  to  a  "down" 
position  Q.e.,  display  on) 

The  grid  size  is  related  to  the  text  height  through  the  scale  parameter. 
This  parameter  defines  hew  many  grid  laUts  equal  one  text  height  tfiit. 

5.3.10.1  Oireeterv  Data 

ENTrPTTTPrNUMBER :  310 

4.3.10.2  Parameter  Data 


Index 

Name 

Im 

Descriotien 

1 

PC 

Integer 

Pont  Number 

2 

FNAME 

String 

Pont  Name 

3 

Integer 

Number  of  the  font  which 
this  definition  supersedes 

4 

SCALE 

Integer 

Number  of  grid  units  which 
equal  one  text  height  uiit 

3 

N 

Integer 

Number  of  characters  in  this 
definition 

6 

ACl 

Integer 

ASCII  code  for  first 
character 

7 

NXl 

Integer 

Grid  location  of  the  next 
character's  origin 
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Index 

Name 

Type 

Description 

1 

NYl 

Integer 

9 

NMi 

Integer 

Number  of  pen  motions  for 
first  character 

10 

PFlj  . 

Integer 

Pen  up  flag 

0  s  Down,  1  s  Up 

11 

Xlj 

Integer 

Grid  location  to  which  the 
pen  is  to  move 

12 

• 

Y^l 

• 

Integer 

e 

• 

• 

9«N.M1*3 

e 

• 

AC2 

e 

a 

Integer 

AiCn  code  for  second 
character 

10<»NM1«J 

NX2 

Integer 

Grid  iocation  of  the  next 
character  origin 

11*NM1*3 

NY2 

Integer 

m 

12«NM1*3 

NM2 

Integer 

Number  of  pen  motions  for 

• 

« 

e 

second  character 

e 

N 

e 

• 

3*4NB2..3«NMi 

e 

Integer 

Last  grid  location  of  last 

i>l 

character 

Additional  Pointers  as  required  (see  2.2.4.4.2). 
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An  example  of  this  entity  using  the  character  in  Figure  A-ftl  is 

FC 

1 

FNAME 

SH  STANDARD 

SF 

SCALE 

t 

N 

<0 

ACl 

<3 

NXl 

11 

NYl 

0 

NMl 

a 

PFl 

0 

XI 

a 

Yl 

t 

PF2 

0 

X2 

t 

Y2 

0 

PF3 

1 

X3 

2 

Y3 

a 

PF% 

0 

X% 

( 

Y% 

• 

e 

a 

• 

In  the  parameter  section  of  the  ICES  file  it  would  look  Uk« 

*  l,EHSTANOARO„l,M,d3,l 

Figure  A>42  provides  another  example. 
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FIGURE  4-42  SECOND  CHARACTER  DEFINITION  EXAMPLE 
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ft.2.9 


C«Mrat  Not*  Entity. 

A  gin«ral  not*  entity  consists  of  on*  or  mor*  text  strings.  Esch  text  string 
eonuins  text,  «  stviing  point,  text  size,  and  angle  of  rotation  of  the  text. 
Examples  of  general  notes  are  shoem  in  Figure  The  PC  value  indicates  the 
font  number  and  is  an  integer.  Positiv*  values  are  pre^lned  fonts.  Negative 
values  point  to  user  defined  fonts  or  modlflcationB  to  a  pre>d*fined  font. 

The  followtng  fonts  erill  be  defined 

0.  Symbol  Pont  (us*  no  longer  recommended) 

1.  Standard  Block 

2.  LeRoy 

3.  Putva 
%.  Pastiont 
S.  Caloemp 
d.  Comp  SO 

7.  Mlfft^Pilffl  Standard 
S.  ISO  Standard 

9.  OIN  Standard 

10.  MUltary  Standard 
U.  Cothie 

12.  News  CotUe 

13.  UghtUn*  Cothie 
U.  Simplex  Roman 
13.  Italic 

Id.  APL 

17.  Century  Schoolbook 
IS.  Helvetica 

1001.  Symbol  Pont  1 

1002.  Symbol  Pont  2 

Fonts  in  the  1000  series  display  symbols  mapped  onto  ASOl  characters  as  shewn 
in  Figures  a  •  10  and  a  .  1 1.  They  do  not  specify  a  character  display  font. 
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P  E  H  -0. 


•  CCHCKAl.  NCT£ 


Font  I  dooo  not  hovo  «  ^inod  dUpioy.  Um  of  Font  t  ifnpUoo  tho  rocoivtng 
systoffl  may  um  any  font  trhtcfi  diiplayt  ttto  appropriato  A5CII  eharacton.  Tho 
intent  of  this  font  U  for  uMgo  w^on  tho  actual  dbptay  of  tho  characton  it  not 
critieal  for  tho  application. 

I 

Font  0  is  an  old  symbol  font  and  should  no  ionfor  bo  uaod.  Fifiro  S  •  12  is  a 
mappinf  symbol  dofinltian  for  font  0. 

tf  tho  FC  numbor  is  not  suffidont  to  dosoribo  tho  font,  a  tost  font  definition 
ontlty  may  bo  uMd  to  daflno  tho  font.  If  a  tost  font  dadinitian  is  boing  usod*  tfm 
nofativo  of  tho  polntor  ralua  for  tho  droetary  entry  of  tho  tost  font  definition 
entity  is  ploead  in  tho  FC  paramotor.  Tho  um  of  die  valuos  VT,  HT.  SL.  A.  and 
tost  start  point  are  shoom  in  Figiro  s>il. 

VitNn  definition  tpaeo.  tho  paramoton  for  tho  tost  Mods  are  appttod  in  tho 
foUowinf  order  (Soo  Flfuro  ^isk 

1)  Oofino  tho  boa  haiifK  (HD  and  boo  width  (VD. 

Tho  rotate  intamai  tost  flag  indeatas  whotfiar  die  tost  bos  Is  flUod  with 
hsriaontal  tost  or  vordeal  tost.  Tho  bos  oAdth  is  msaoiBwd  from  tho  tost 
start  paint  in  the  positiva  XT  dtooetion  and  die  boo  hai|fR  is  masourod  in 
tho  positivo  YT  droetian  from  tho  tost  start  paint*  boforo  tho  retsdon 
angle  (A)  is  appiiod. 

2)  Tho  slant  angle  is  then  applied  to  each  indvtdual  dtarsetor.  For  horUomal 
tost  It  is  moostood  from  tho  XT  asls  in  a  countarelodcwiM  droction.  For 
MTtieal  tost  tho  slant  angle  is  mooatrod  from  tho  YT  ails. 

3)  Tho  rotation  angle  is  than  appliad  to  tho  test  Mods.  This  rotation  is 
appiiod  in  a  eountorelockwiso  direction  about  tho  tost  start  point.  Tho 
piano  of  roution  is  tho  XT.  YT  piano  at  tho  depth  ZSn  (where  ZSn  is  tho 
value  given  for  tho  tost  start  point). 
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212  >  CENERAL  NOTE 


4)  Th«  mirror  oporation  is  porformod  n«*t.  Tho  vaiu*  1  indicates  the  mirror 
^«i€  is  th«  (rotated)  line  perpendicular  to  the  text  base  line  and  through  the 
text  start  point.  The  value  2  indicates  the  mirror  axis  is  the  (routed)  test 
base  line. 

Finally!  the  Transformation  Matrix  entity  is  used  ta  specify  the  relative  position  of 
definition  space  within  model  space. 

The  number  of  characters  (NCn)  murt  always  be  equal  to  the  character  oouit  in  iu 
eorrespendint  text  string  (TEXTn). 
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FI6.  H-H  COBUO.  NOTE  EWUm  OF  TEXT  OFEUTIONS 


212  -  --  i 


k.2.9.1 


».2.9.3 


9^9.* 

9.X9.«.1 


•.2.9.«.2 


AAl.  NUtft 


Th«  graphical  raprtsantation  and  raercation  of  notts  with  a  apodal 
strvicturo  art  handlod  by  tho  visa  of  tha  Form  Numbar  in  Fiald  13  of  tha 
Siraetery  Entry  for  this  antity.  A  syitam  to  accommedata  thaaa  notas  is 
outlinad  balow.  Any  strings  aftar  those  spadfiad  by  tho  form  number  are 
eenalderad  additional,  appended  strings  that  are  net  related  in  any  partio 
lar  manner  te  the  pravieualy  referenced  strinp. 

In  the  event  that  a  string  naeesaary  fer  tha  defined  stnjctwa  is  net  present 
in  the  originating  system's  note,  a  nufi  string  shall  be  insvtad  in  the 
general  note  antity  te  take  the  place  of  the  neni^dstent  string  te  maintain 
the  structure  of  the  data. 

Notes  that  contain  fractional  notation  vnll  be  raprasented  as  mixed 
numerals.  This  is  dene  through  the  um  ef  four  consecutive  strings 
representing  the  whole  number,  the  numerator,  the  denominator,  and  the 
divisor  bar.  These  are  examples  of  the  divisor  bar  strinp 

IH/  IH-  2H-  1H_ 

Tha  following  form  numbers  for  the  general  note  are  «Md  te  maintain  tho 
grapMcai  representation  of  the  originating  system's  netei 

Form  Oi  Simple  Note  (default)  •  A  ganeral  note  of  one  or  more  strinp 
such  that  a  text  string  is  net  related  in  any  manner  to  another 
string  in  the  same  general  note  entity.  • 

Form  1>  Dual  Stack  •  A  general  note  of  two  or  mere  strinp  where  the 
first  two  are  related  in  a  manner  such  that  they  are  both  left 
justified  and  the  second  string  is  displayed  'below*  the  first. 
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A.2.9.A.3 


A.2.9.4.3 


*.2.9.9^ 


A^9.A.7 


A.2.9.A4 


Form  2x  Imb«dd«d  Font  Chango  •  A  gonorsi  not*  of  two  or  mor*  strings 
that  is  int*nd*d  as  a  stngl*  string  but  was  divided  to  accommodate 
a  font  change  in  the  string, 
xxxxyyy  xxxx 

Form  >  Supersff ipt  •  A  general  note  of  two  or  mere  strinp  where  the 
second  string  is  a  superscript  of  the  first  string. 

Form  At  Subscript  •  A  general  net*  of  two  or  more  strinp  where  the 
second  string  is  a  substfipt  of  the  first  string. 

Tfl 

Form  3i  Sup*r«/Sub>s9ipt  •  A  general  net*  of  three  or  mor*  strinp  where 
the  second  strtog  is  a  superscript  of  Pm  first  string  and  the  third 
string  is  a  subscript  of  the  first  string. 


Form  <1  Multiple  Staeic/l.eft  Justified  •  A  goneral  net*  where  all  strinp 
are  left  jusdfled  to  a  common  margin.  Those  strinp  originated  as 
a  "porapaphe^  noto. 


rrrrrrm 


Form  7:  Multiple  Staek/Center  Justified  >  A  general  net*  where  all  strinp 
are  center  jusdfled  to  a  common  axis. 


rm 

txxxztt 
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4.2.9.*.R 


A.2.9.A.10 


4.2.9.  A.  11 


4.2.9.4.12 


Form  St  Multipl*  Staek/Right  Juttifiod  •  A  general  note  «here  all 
strings  are  right  juanlied  to  a  common  margin, 
xxxxxxxxxx 

yyyyyyy 

rxax«« 

Form  lOOt  Simple  Fraction  •  A  general  note  of  four  or  mere  strings 
where  the  first  fotr  strings  define  a  mixed  numeral  as 
defined  in  4.2.9.3. 

yyy 

XX  — 

zzz 


Form  101:  Dual  Stack  Fraction  •  A  general  note  of  eight  or  mere 
strings  which  represent  twe  mixed  numerals  as  defined  in 
4.2.9J.  These  mixed  numerals  are  related  such  that  the 
fifth  through  the  eighth  strings  are  displayed  below  the  fir^ 
through  the  fowth  strings  respectively. 


Form  102:  Imbedded  Font  Change/Ooubie  Fraction  •  This  general  note 
originated  as  ^  single  string  but  was  split  to  accommodate  a 
font  change  for  a  special  character  in  the  fifth  string.  This 
is  a  general  note  of  nine  or  more  strings  where  the  first  and 
sixth  strirp  represent  the  whole  number  string  of  a  mixed 
numeral  as  defined  in  4.2.9.J.  The  Qfth  string  is  a  dtaracter 
(or  characters)  that  was  set  apart  to  accommodate  the  font 
diange. 
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Form  109:  Sup«r-/Subscript  Fraction  -  A  gtnorai  net*  ot  twelve  or 
more  strings  where  the  first,  fifth,  and  ninth  strings 
represent  the  whole  number  string  of  a  mixed  numeral  as 
defined  in  a.2,9.3.  The  second  and  third  mixed  numerals  are 
the  superscript  and  subscript  respectively  of  the  first  mixed 
numeral. 
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4.2.9J  Diftetorv  Data 

ENTITY  TYPE  NUMBER  :  212 

*.2.9.6  P«r«iwt«r  D«t« 


Indox 

Namo 

Ixss 

Ocseriotion 

i 

NS 

Intagor 

Numbor  of  text  strings  in 
fonoral  note 

2 

NCI 

Intogor 

Numbor  of  eharaetors  in 
first  string  (TEXTl)  or 
zaro.  Tho  numbor  of 
dtaractors  (NCn)  must 
always  bo  oqual  to  tho 
eharaetor  eouit  of  its 
eorrosponding  toxt  string 
(TEXTn) 

9 

WTl 

Roal 

Bex  sridth 

* 

HTl 

Rool 

Bos  height 

3 

PC 

Intogor  or  P^tor 

Pont  eharaetoristie 
(Default  a  1) 

6 

SLl 

Roal 

Slant  angle  of  TEXTl  in 
radians  (pi/2  is  tho  value 
for  no  slant  angle  and  is 
tho  default  value) 

7 

A1 

Roal 

Rotation  angle  in 
radians  for  TEXTl 

t 

Ml 

Intogor 

Mirror  flag 

O-ne  mirroring 
1  •  mirror  axis  is 
porpondicular  to  tost 
baso  Uno 


2  •  mirror  axis  is  text 

baso  Uno 


9 

VHl 

Intogor 

Rotate  inttmal  text  flag 
((VtoxT  horizontal.  Utoxt 

voracal) 

10 

XSl 

Roal 

First  toxt  start  point 

11 

Y51 

Roal 
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12 

ZSl 

Raal 

2  dopth  from  XT,  YT 
piano 

13 

TEXTl 

String 

First  tore  string 

I« 

NC2 

Intogor 

Number  oi  eharocton  in 
second  text  string 

UNS*12 

TEXTNS 

String 

Last  text  string 

2*NS*12 

NCNS 

Intogor 

Number  of  characters  in 
last  text  string 

Additional  Pointan  as  raquirod  (sot  2.2.%.^) 
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100  •  CIRCULAR  ARC 


3.2  Circular  Are  Entity 

A  drcuiar  are  is  a  eonnaetad  portion  of  a  parant  eircia  which  eenaisti  of 
mora  than  an«  point.  Tha  dafinition  spaca  coordinate  system  is  always 
chosen  so  that  tha  dreular  are  lias  in  a  plana  either  OBinddant  with  or 
parallel  to  the  XTf  YT  piano. 

3.2.1  A  dreular  are  datarminas  Clique  are  and  points  and  an  are  eantar  point  (tha 
cantar  of  the  parant  eirela).  By  eonaidaring  tha  are  and  points  to  be 
anumaratad  and  Ustad  In  an  ordered  manner,  start  point  first,  followed  by 
terminate  point,  a  diraetion  with  raapaet  to  definition  spaea  ean  ba  asa^ 
eiatad  with  tha  are.  Tha  ordering  of  tha  and  poinu  eorraaponds  ta  tha 
ordering  nacaaaary  for  tha  are  to  ba  traead  out  in  a  ee«attareloefcwiaa  mannar. 
This  eonvantlon  servos  to  dbtinguish  tha  daairad  dreular  are  from  its 
com  pi  am  antary  are  (eomplamantary  with  rasp  act  to  tha  parant  eirdaL  Refer 
to  Saetlon  3.1.2  for  information  relating  ta  uaa  of  tha  term  eataRarelediwisa. 

3.2.2  Tha  draction  of  tha  are  with  raspaet  to  modal  space  is  datarminad  by  tha 
originai  eo««Karelod(ofiaa  draetian  of  tha  are  within  definition  space,  in 
eonjwietion  with  tha  action  of  tha  transformation  mavis  on  tha  «e. 

3.2J  In  tha  event  that  a  paramatorisatlon  is  raqiirad  but  not  given,  tha  default 
paramatarisatlon  iai 


C(t)  »  (XI  *  R»cos  t,  Y1  ♦  R*sin  t,  ZD 
for  t2  4  t  <  t3 

where,  for  i  a  2  and  3, 

G)  R  a  sqrt((Xi-Xl)»*2  ♦  (Yl-Yl)**2) 

Qi)  ti  is  sueh  that  (R*eas  ti,  R*sin  ti)  a  (Xi  •  XI,  Yi  •  Yl) 
and 

0  <  t2  <  2*P! 

0  d  t3  -  t2  4  2*PI 


TOO  -  CIRCULAR  arc 


Ex*mpl«  oi  th«  circuiAf  »e  .ntity  «r»  shown  in  Figurt  3-1.  In  Exampio  3  of 
Fifurt  3.1,  tho  soUd  irc  is  Mfinod  using  point  A  as  tho  stvt  point  and  point 
B  AS  tho  torminoto  point.  If  tho  eomptomontAry  doshod  arc  woro  dosirod.  tho 
first  ondpoint  Ustod  in  tho  porAmotor  data  ontry  would  bo  B,  and  tho  socond 
would  bo  A. 


ENTITY  TYPE  NUMBER  :  100 

Pirainotnr  Dota 


indoic 

Namo 

Typo 

Ooscrietion 

1 

2T 

Roai 

Parallol  ZT  displaeomont  of 
arc  from  XT,  YT  piano 

2 

XI 

Roal 

Arc  cantor  «| 

3 

Y1 

Roai 

Arc  cantor  ordnato 

A 

X2 

Roal 

Start  point  ahadasa 

3 

Y2 

Roai 

Start  point  ordinato 

« 

X3 

Roal 

Tormlnato  point 

7 

Y3 

Roal 

Torminato  point 
ordinato 

Addtlonal  Pointors  as  roquirod  (soo  2.2.A.«.^. 
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no 
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3.3  CompoMf  Ctgy  gntitv 

A  eempositt  curve  is  a  connected  curve  th«t  results  from  the  grouping  of  certain 
individual  constituent  entities  into  a  logical  tout. 

3.3.1  A  oompoalte  curve  is  defined  as  an  ordered  Ust  of  entities  of  the  following  typeai 
point,  line,  circular  arc,  conic  are,  parametric  spline,  rational  B>spline,  and 
connect  point.  The  list  of  entities  appears  in  the  parameter  data  entry.  There, 
each  entity  to  appear  in  the  defining  Ust  is  indcated  by  means  of  a  pointer  to 
the  directory  entry  of  that  entity.  The  order  within  the  defining  list  is  derived 
from  the  order  of  the  listing  of  these  pointers. 

3.3.2  Each  constituent  entity  has  its  own  transformation  matrix  and  tfsplay  attributes. 
Each  constituant  entity  may  have  text  or  properties  associated  with  it.  Because 
the  constituent  entities  are  subordinate  to  the  composite  entity,  the  Subordinate 
Entity  Switch  (digits  3^  in  directory  entry  field  9)  of  each  constituant  entity 
should  indicate  a  physical  dependency. 

3.3.3  A  composite  orve  is  a  drected  arve,  having  a  start  point  and  a  tarminate 
peine  The  direction  of  the  composita  curve  is  induced  by  die  direction  of  the 
constituant  curve  entitios  Oa,  those  constituant  entities  other  than  the  point 
entity)  in  the  following  wayi  The  start  point  for  the  composite  curve  is  the  start 
point  of  the  first  curve  entity  appearing  in  the  defining  list.  The  terminate  point 
for  the  composite  arve  is  the  terminate  point  of  the  last  ewe  entity  appearing 
in  the  defining  Ust.  Within  the  defining  Ust  itself,  the  terminate  point  of  each 
constituent  curve  entity  has  the  same  coordinates  as  the  start  point  of  the 
succeeding  curve  entity. 

3.3.a  The  point  and  connect  point  entities  are  included  as  allowable  entity  types  so 
that  properties  or  general  notes  can  be  attached  to  either  the  start  point  or  the 
terminate  point  of  any  constituent  arve  entities  in  the  defining  list. 

A  logical  connection  relationship  can  be  indicated  by  having  two  composite 
curves  or  a  composite  curve  and  a  network  subfigire  reference  the  connect  point 
entity.  For  the  special  case  of  the  logical  connection  of  a  connect  point  on  one 
subfigure  instance  to  a  connect  point  on  another  subfigure  instance  a 
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3J.5 


eompoutt  curve  is  sllowed  whose  list  contsins  =nly  two  connect  point  entities 
with  no  intervening  curve  entity.  There  ere  cartsin  restrictions  rsgsrding  the 
use  of  the  point  entity  in  s  composite  entity.  They  sret 

«.  Two  point  or  connect  point  entities  esnnet  sppoar  consecutively  in  the 
defining  list  isiiess  they  are  the  only  antitieB  in  the  composite  curve. 

b.  If  a  point  or  comeet  point  entity  and  a  curve  entity  are  adjacent  in  the 
defining  list,  then  the  coordinates  of  the  point  or  connect  point  entity  mint 
agree  with  the  coordinates  of  the  terminate  point  of  the  curve  entity 
whenever  the  cirve  entity  precedes  the  point  or  conneet  point  entity,  and 
must  agree  with  the  coortfnates  of  the  start  point  of  the  curve  entity 
whenever  the  curve  entity  follosrs  the  point  or  connect  point  entity. 

e.  A  composite  arve  cannot  conaist  of  a  point  entity  alone  or  a  single  connect 
point. 

In  the  event  that  a  parametrixation  is  required  but  not  given,  the  default 
parametriaation  of  the  composite  curve  is  obtained  from  the  parametrixation  of 
the  constituent  orvea  as  defined  beiev.  As  point  and  connaet  point  ontitiaa  do 
net  contribute  to  die  parametrixation  of  a  eompoaite  curve,  they  are  not 
conaidored  in  the  definition  beiev. 

• 

Let 

C  be  the  composite  arvei 

N  be  the  number  of  censtituant  curves  (N>  1)| 

CCG)  be  the  i-th  constituent  cvrve,  for  each  i 

such  that  14i<N  i 

PSQ)  be  the  parametric  value  of  the  start  of  CCQ) ; 

PCQ)  be  the  parametric  value  of  the  and  of  CCQ) ; 

no)  be  0.0 1 

T(i)  be  the  sum  from  Jal  to  |ai  of  (PSij)  •  PS(i)), 

tar  each  i  such  that  14i  4  N. 


113 


259 


102  .  COMPOSITE  CURVE 


T)i«n 

(1)  the  pvvnctrie  valuM  of  C  ran(«  from  T(0)  to  T(N) ;  and 

(2)  C(u)  a  CCQ)  (u  •  T0>i)  a  PS  (i))  whoro  u  is  a  paramotrie  vaiua  such  that 

Ta-l)4u<m 

A  eompesita  ewv*  eonsistint  solaly  of  point  and/or  eonnoet  point  antitiasi  will 
net  be  given  a  parametrization. 

3.3.4  In  this  aeetient  an  example  of  a  parametrization  of  a  eompeaite  eieve  antity  is 
given. 

Let  Na3  and  for  each  I  such  that  14  i  43*  let  CCQ)  be  the  i-th  eenotituant  curve 
of  die  eempoaite  ewe  C  Assume  die  parametrie  mluas  of  die  start  and  end 
points  of  oaeiiCCQ)  are  given  by  the  table 

1  pso)  peo) 

1  0.0  o.« 

2  3J  3.3 

3  0.0  0.3  • 

Then  T(0)  •  0.0,  T(l)  «  0.a,  T(2)  a  0.4,  T(3)  a  0.9,  and  the  composite  ewe  C,  is 
defined  from  0.0  to  0.9. 

This  situation  described  is  illustrated  by 


CC(2) 

The  curve  combining  CC(1),  CC(2),  and  CC(3)  represents  the  composite  ewe  C. 
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3.3.7  An  cxampl*  of  a  eompositt  curv«  entity  is  shown  in  Figure  3>2 

3.3.S  Direetorv  Data 

E.NT1TY  TYPE  NUMBER  :  102 


Description 
Number  of  entities 

Pointers  to  directory 
entries  lor  the  constituent 
entities 


I 

I 

I 

I 

I 

I 

I 

I 

I 

1 

I 


I 

[ 

I 

■ 


3.3.9  Peremeter  Pete 
Index  Name 


N 

OE 


IZ2S 

Integer 

Pointer 


N«l  OB  Pointer 

Add  tionel  Pointers  ss  required  (see  2.2.b.b.2). 
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3.*  Cawie  Are  Entity 

A  CDfiic  are  is  a  bo«jndad  eonnaetad  portion  of  a  parant  conic  curva  which 
consists  of  mora  than  ona  point.  Tha  parant  conic  etrva  is  aithar  an  dlipsa,  a 
paraboUt  or  a  hyparboU.  Tha  dafinition  spaea  eaordinata  systam  is  aiways 
chesan  so  that  tha  conic  are  lias  in  a  plana  aithar  eoineidant  with  or  parailal 
to  tha  XT,  YT  plana.  Vithin  such  a  plana,  a  conic  is  daflnad  by  tha  six 
eoafiieiontt  In  tha  foilowinf  aquation. 

A*XT^  ♦  8»XT»YT  *  C*rH  ♦  0*XT  ♦  B*YT  ♦  P  •  0 

3.4.1  Bach  coafliciant  is  a  raal  numbar.  Tha  dallnitions  of  allipaa,  parabola,  and 
hyparbola  in  tarms  of  thaaa  six  eooffieiants  ara  |ivan  balow. 

3.4.2  A  conic  are  dotcrminaa  tatiqua  are  endpoints.  A  eonie  arc  is  daflnad  within 
doflnition  spaea  by  tha  six  cooffieianu  abova  and  tha  two  endpoints.  By 
conaidorinf  tha  conic  andpoinu  to  ba  anumaratad  and  Ustad  in  an  ordarad 
mannar,  start  point  followad  by  tarminata  point,  a  dlraetion  with  raapaet  to 
dafinition  spaea  cm  ba  aasoeiatad  with  tha  are.  In  ordar  for  tha  daairad 
aillptieal  «e  to  ba  dstinquishad  from  its  compiamantary  aUlpdeal  are,  tha 
fraction  of  tha  daairad  aiitptieai  are  must  ba  eountardoefcwisa.  to  tha  eaaa 
of  a  paraboU  or  hyparbola,  tha  paramators  glvan  to  tha  paramrtar  data 
saedon  tatiquoly  daflna  a  portion  of  tha  parabola  or  a  pardon  of  a  branch  of 
tha  hyporbolai  tharafora,  tha  eonespt  of  a  cDuntarelodtwisa  Araetion  is  not 
appliad.  (Rafar  to  Saedon  3.1.2  for  information  concaminf  uaa  of  tha  torm 
"countardoekwisd*  J 

3.4.3  Tha  dlraetion  of  tha  conic  are  with  raspaet  to  modal  spaea  is  datorminad  by 
tha  original  dlraetion  of  tha  are  within  dafinition  spaea,  in  coniimction  with 
tha  action  of  tha  transformation  matrix  on  tha  are. 
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3.A.A 


Tb«  definitions  of  the  terms  ellipse,  persPoU,  end  hyperbole  ere  given  in  terms 
of  the  quantities  Ql,  Q2,  end  Q3«  These  quantities  ares 


01  «  deurraiaau  of 


A 

M/2 

D/2 

M/2 

C 

m 

D/2 

m 

r 

03  «  detafBinatt  at 


Qi»A*C 


3.4.3  A  parent  conic  cwve  is 

An  elUpse  if  Q2>0  and  Ql  *  Q3<Q. 

A  hyperbola  if  Q2d0  and  Ql  t  C. 

A  parabola  if  Q2  ■  0  and  Ql  i  0. 

An  example  of  each  type  of  certie  arc  is  shewn  in  Rgure  >3. 

3.4.4  These  entities  which  can  be  represented  as  various  defsnerate  forms  of  a  conic 
equatien  (Point  and  Line)  must  net  be  put  into  the  Entity  Type  i04|  more 
appropriate  Entity  Types  exist  for  thoM  forms. 


Because  of  the  numerical  sensitivity  of  the  implicit  form  of  the  conic 
description,  a  receiving  system  net  using  that  form  as  its  intsmai  representation 
for  conics  need  not  be  expected  to  correctly  process  conics  in  this  form  vniess 
they  are  put  into  a  standard  position  in  definition  space.  A  conic  arc  entity  is 
said  to  be  in  a  standard  position  in  definition  space  provided  each  of  its  axes  is 
parallel  to  either  the  XT  axis  or  YT  axis  and  provided  it  is  centered  about  the  ZT 
axis.  For  a  parabola,  use  the  vertex  as  the  origin.  The  conic  is  moved  from  this 
position  in  definition  space  to  the  desired  position  in  space  with  a  transformation 
matrix  (Entity  type  124). 


The  form  number  is  regarded  as  purely  informational  by  such  a  postprocessor. 
Further  details  may  be  found  in  Appendix  E. 
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104  -  CONIC  ARC 


In  the  event  th*t  «  peremeterization  is  required  but  not  given,  the  detauit 
parameterization  is: 


Parabola 

case  A  and  E  >0.0 
if  XI  <  X2 

C(t)  «  (t,  .(A/B)*t««2,  m 
where,  for  i  a  1  and  2,  ti  a  Xi. 

if  X2  <  XI 

C(t)  a  (-t,  -<A/E)«t**2,  2T) 
where,  for  i  a  1  and  2,  ti  a  .Xi. 

case  C  and  0  >0.0 

if  YI  <  Y2 

Clt)  a  (..(C/0)*t*»((2,  t,  IT) 
where,  for  i  a  1  and  2,  ti  a  Yi. 

if  Y2  <  YI 

C(t)  a  WC/0)«t**2,  -t,  m 
where,  for  i  a  1  and  2,  ti  a  .Yi. 


for  tl  ^  t  4  t2 


for  tl  <  t  4  t2 


for  tl  ^  t  4  t2 


fortl  4  t  4t2 


Emose 

C(t)  a  (a*coe  t,  b^iin  t,  IT) 
for  tl  <  t  <  t2 

where 

a  a  sqrt(.P/A) 
b  a  sqrt(-F/C) 

and,  for  i  a  1  and  2.  ti  is  such  that 

U)  (a*cos  ti,  b*ain  ti,  IT)  a  (Xi,  ri,  IT) 

(ii)  0  <  tl  <  2*PI 

(iii)  0<  t2-ti<  2»P! 


Hyperbola 

case  F*A  <  0.0  and  F«C  >  0.0 


a  a  $qrt<-F/A) 
b  a  KTtlF/C) 
and,  for  i  a  1,2 
ti  IS  such  that 

(i)  (a*sec  ti,  b*tan  ti,  IT)  a  (Xi,Yi,IT) 
Ui)  -Pl/2<tl,t2<Pl/2 
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if  tl  <  t2 

C(t)  a  U*s«e  t,  b*tan  t,  ZT) 
if  t2<tl 

C(t)  a  («*s«c(-t),  b*tan<«t),  ZT) 

esM  P*  A  >  0.0  and  P*C  <  OU) 
l«t 

a  a  sqrifP/A) 
b  a  S7t(.p/C) 
and,  for  i  a  1,2 
ti  is  such  that 

a)  (a«tan  ti,  b*soc  ti,  ZT)  a  (Xi,Ylxn 
Qi)  -Pt/ZKtUtZdPl/Z 

iftl^tZ 

C(t)  a  (a«tan  t,  b*s«e  t,  ZT)  for  tl  4^  t  ^  t2 

if  t2  <  tl 

C(t)  a  (a*tan(*t),  b*sae(«t),  ZT)  for  -tl  ^  t  ^-t2 

3.44  Field  13  of  tho  directory  entry  accommodates  a  Form  Number.  For  this  entity, 
the  options  are  u  fotlowsi 

FORM  Meanina 

0  Form  of  parent  conic  oarve  must  be  detemUhed  from  the  general 

equation. 

1  Fvent  conic  curve  is  an  ellipse  (See  example  1,  rifure  3>3). 

2  Parent  conic  curve  is  a  hyperbola  (See  example  2,  Figure  3-3). 

3  Parent  conic  curve  is  a  parabola  (See  example  3,  Figure  3-3). 


for  1  ^  t  4  t2 

for-ti  ^  t4-t2 
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3.4.9  Dir«ctofv  Data 

E.NT1TY  TYPE  NUMBER  :  104 

3.4.10  Par  imfr  Pmtm 


Indoa 

Naino 

Typo 

1 

A 

Roai 

2 

B 

Roal 

3 

C 

Roai 

4 

0 

Roal 

3 

B 

Roai 

< 

P 

Roal 

7 

rr 

Roal 

t 

XI 

Roal 

9 

YI 

Roal 

10 

X2 

Roal 

11 

Y2 

Roal 

AMtional  Pointtn  aa  raquirad  (m*  2^«.4.2). 
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D«»criotion 

Conic  Coofficiont 

Conic  Cooflidtnt 

Conic  Coofficiont 

Conic  Coofficiont 

Conic  Coofficiont 

Conic  Coofficiont 

ZT  Coordbwto  of 
piano  oi  Oofinitian 

Start  Point  Abociaas 

Start  Point  Ordnato 

Torminato  Point 
Abaciaaa 

Torminato  Point 
Ordnato 
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3.3  Cooioui  OAta  Entity 

This  entity  stores  data  points  in  the  form  of  pairs,  triples,  or  septuples.  An 
interpretation  flag  value  signifies  which  of  these  forms  is  being  used.  This  value 
is  one  of  the  parameter  data  entries.  The  interpretation  flag  is  abbreviated 
below  by  the  letters  IP. 


Data  points  within  definition  space  which  lie  within  a  single  plane  are  specified 
in  the  form  of  XT,  YT  coordinate  pairs.  In  this  ease,  the  common  ZT  value  is 
also  needed.  Data  points  arbitrarily  located  within  definition  space  are  specified 
in  the  form  of  XT,  YT,  ZT  coordinate  tripiea.  Qata  points  within  definition 
space  which  have  an  associated  vector  are  specified  in  the  form  of  sextuplesi  the 
XT,  YT,  ZT  coordinates  are  specified  first,  followed  by  the  i,  j,  k  coordinates  of 
the  vector  associated  with  the  point.  (Note  that,  (or  an  associated  vector,  no 
special  meaning  is  impUcitJ 

Field  13  of  the  directory  entry  accommodates  a  Form  Number.  For  this  entity, 
the  options  are  as  foliowsi 


FORM  Meanina 

1  Data  points  in  the  form  at  coordbiate  pairs.  AU  dan  points  Ue  in 
a  plane  ZTa  constant.  (!P«1) 

2  Oan  points  in  the  form  of  coerdbiate  triples.  (IPa2) 

3  Oan  points  in  the  form  of  sextuples.  QPaJ) 

11  Data  points  in  the  form  of  coordnate  pairs  which  represent  the 
vertices  of  a  planar,  piecewise  linear  cwve  (piecewise  linear 
string  is  sometimes  used).  All  dan  points  lie  in  a  plane 
ZTsconstant.  (IPai) 

12  Data  points  in  the  form  of  coordnate  triples  which  represent  the 
vertices  of  a  piecewise  linear  curve  (piecewise  linear  string  is 
sometimes  used).  QPag) 

13  Data  points  in  the  form  of  sextuples.  The  first  triple  of  each 
sextuple  represents  the  vertices  of  a  piecearise  linear  ewe 
(piecewise  linear  string  is  sometimes  used).  The  second  triple  is 
an  associated  vector.  (Ipa3) 
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21  CtnterUn*  Entity  through  eirel*  canttn  (IPml) 

31  Section  Entity  Form  31  (IP«1) 

32  Section  Entity  Form  32  (1P«1) 

33  Section  Entity  Form  33  dPal) 

34  Section  Entity  Form  3*  (IPel) 

33  Section  Entity  Form  33  QPsl) 

%  Section  Entity  Form  34  (IP«1) 

37  Section  Entity  Form  37  QPal) 

3t  Section  Entity  Form  3S  (IPsl) 

60  Witneu  Line  Entity  QP*!) 

63  Simple  Cloted  Area  Entity  QP«1) 

The  linear  path  la  an  ordered  set  of  points  in  either  2-  or  3-4menaionai  space. 

These  points  define  a  series  of  linear  segments  along  the  consecutive  peinu  at 
the  path.  The  segments  may  aoss  or  be  coincident  with  each  other.  Paths  may 
close,  i.e.,  the  first  path  point  may  be  identical  to  the  last. 

The  linear  path  is  implemented  as  two  forms  of  the  copious  data  blodc  (entity 
number  106).  Form  11  la  for  2>4fflanBional  paths  and  form  12  is  for  3> 
dimensional  paths.  This  entity  will  be  doaely  asaedated  with  propertlea 
indicating  fvnctionallty  and  fabrication  parameters,  such  as  Line  Widening. 

Refer  to  the  centerline  and  witnen  line  entities  in  Section  a  of  this  spedfieation 
for  examples  of  Form  Numbers  20,  21  and  60.  Each  of  theae  annotation  entities 
contains  a  description  of  how  the  asaedated  copious  data  are  to  be  interpreted. 

Forms  31-36  provide  for  the  tramfer  of  graphical  information  and  are  defined 
here  for  compatability  with  previous  versions  of  the  spedfieation.  The 
Sectioned  Area  Entity  (type  230)  provides  a  more  compact  method  for 
transferring  this  information. 

A  simple  dosed  area  is  a  bounded  region  of  XY  coordinate  space  represented  by 
a  set  of  points  that  forms  a  series  of  eonneeted  linear  segments.  Theae  segments 
must  form  a  dosed  loop,  i.e.,  the  first  point  of  the  boundary  of  the  area  and  the 
last  paint  must  be  identical.  No  segments  of  this  entity  are  allowed  to  intersect 
or  be  coincident  except  for  the  dosing  of  the  entity  at  the  initial  and  final 
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point*.  Thi*  ontity  «U1  bo  doioly  roUtod  to  proportioi  th«t  indicato 
(wictionoiity  of  closod  royions,  such  as  Rofion  Fill  and  Rogton  Rostrictien. 

^  iniplomofitod  as  Form  63  of  entity  106.  tbo  copious  data  block. 


3>3.1  Difoctorv  Dou 

ENTITY  TYPE  NUMBER  i  106 

3>3.2  Pbramotar  Data 


tndox 

Nawo 

Tvoo 

Ooseriotion 

1 

IP 

Intogor 

Intorprotation  Flag 

tPal  a:,y  pain,  eommon  z 
lPo2  %,ya  eoardlnatoi 

IP«3  z,ya  eaortfnatoB  and 


Utkvoetan 


2 

N1 

Intagor 

Numbar  of  ivtviplas 

For  1P«1  (x,y  pain,  eommon  z)i 

3 

ZT 

Raal 

Common  z  dsplacamant 

« 

XI 

Raal 

Pint  data  paint 

3 

0 

Y1 

a 

Raal 

a 

Pint  data  point  ordbiata 

a 

a 

3*2N 

a 

YN 

a 

a 

Raal 

a 

a 

Last  data  point  ordnata 

For  IP*2  (x,ya 

triplask 

• 

3 

XI 

Raal 

Pint  data  point  z  valuo 

a 

Y1 

Raal 

Pint  data  point  y  vaiuo 

3 

• 

• 

Z1 

a 

Raal 

a 

Pint  data  point  z  vaiuo 

a 

« 

2*3N 

a 

ZN 

a 

a 

Raal 

a 

a 

Last  data  point  z  vaiuo 

u« 
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106  -  COPIOUS  DATA 


For  IPa3  (x,y,z,i»j,k  s«xtupl«s): 


3 

XI 

Real 

Pint  data  point  x  valua 

A 

Y1 

Real 

Pint  data  point  y  vaiua 

3 

.  Z1 

Raal 

Pint  data  point  z  vaiua 

4 

tl 

Raal 

Fim  data  point  i  vaiua 

7 

31 

Raal 

Pint  data  point  J  vaiua 

t 

• 

K1 

• 

Raal 

a 

Pint  data  point  k  vaiua 

a 

• 

• 

2*iN 

• 

• 

KN 

a 

a 

Raal 

a 

a 

Last  data  point  k  vaiua 

AdditioMl  painttn  «s  r«quir«d  (sm  s«e.  2^A.A.2). 
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108  -  PLANE 


127 
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.  3-5  SINGLE  PARENT  ASSOCIATIVITY  AS  USED  NITH  A  COLLECTION 

OF  BOUmO  PLANES 


112  •  PAKAHETltlC  SPLZHS  CURVE 

3.A  P»f awtrie  SoUtx  C>gv«  Entity 

(Corauit  Appendix  0  for  additional  mathomatical  dotaiia) 

The  parametric  spline  orve  is  a  sequence  of  parametric  pelynomiai  seiments. 
The  CTYPC  value  in  Parameter  1  indicates  the  type  of  curve  as  it  was 
represented  in  the  tending  <pre>precessing)  system  before  conversion  to  this 
entity. 

3.2.1  The  N  polynomial  segments  are  delimited  by  the  breakpoints  T(l),  T(2), 
~nT(N«l).  The  coordinates  of  the  points  in  the  i«th  segment  of  the  etrve  are 
given  by  the  following  cubic  polynomials  (the  coefficients  0,  or  C  and  0  will  be 
aero  if  the  polynomials  are  of  degrees  2  or  .1,  respectively^ 

J(«)«dJrrDw  jr(i)  YfOrCi)  VeATCD 

r(a)«dr(iH  jr(/)  i*cr<n  v 

r(i)<  »<  r(M>i),Mi_jir 

jwe-n/) 

In  order  to  avoid  degeneraqrt  for  each  i  at  least  one  of  the  nine  real  coefficients, 
SXQ),  CXC).  OXG),  aVG),  CYG),  OYG),  SZQ),  CZQ),  and  OZG)  mmt  be  netfavo. 

3J.2  If  the  spline  is  planar,  it  must  be  parametrized  in  terms  of  the  X  and  Y 
polynomials  only.  The  Z  polynomial  will  then  be  zero  except  for  each  i,  the  AZG) 
term  which  indicates  the  Z*depth  in  deflnitian  space. 

3.2.3  The  parameter  H  is  used  as  an  indicator  of  the  smoothness  of  the  orve.  If  HaO, 
the  ewe  is  contlnueus  at  all  breakpoints.  If  Hal,  tfie  ewe  is  continuous  and 
has  slope  continuity  (see  section  2.3  of  PAUX79)  at  ail  breakpoints.  If  Ha2,  the 
ewe  is  continuous  and  has  both  slope  and  ewatwe  continuity  at  all  breakpoints 
(see  section  2.3  of  faux79). 
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112  •  PAKAHeiAiC 


3«S>A  To  ofiAbi#  dotorminotion  of  tho  tortninAto  point  and  dorivativos  without 
computing  tho  polynomiah,  tho  Nth  polynomials  and  their  derivatives  are 
evaluated  at  u  a  T(N«t).  These  data  are  divided  by  appropriate  factorials  and 
stored  following  the  polynomial  coefficients.  For  example,  the  name  TPY3  will 
be  used  to  designate  1/3!  times  the  third  derivative  of  the  Y  polynomial  for  the 
Nth  seginent  evaluated  at  uaTfN'*!),  the  parameter  value  corresponding  to  the 
terminate  point.  Note  that  these  data  are  redimdant  as  they  are  derived  from 
the  data  defining  die  Nth  polynomial  segment. 


3.1.3 

An  example  of  a  parametric  spline  is  shown  in  Pigire  VT. 

Adtftional  examples 

34.1 

3X7 

are  shewn  in  Figure  3^ 

Oireeterv  Data 

ENTitV  TYPE  NUMBER  t  112 

Parameter  t3ata 

Index 

Name 

I2BS 

Oestfiotion 

1 

CTYPE 

Integer 

Spline  Type 
(IsUnear 
2>Qua*atic 
3-Cuhie 

teVilaeiwFowler 
3«Modfied 
WiisoiwFowler 
laS  SpUne) 

2 

H 

Integer 

Degree  of  eoi^ 
tinuity  with 
respect  to  are 
length 

3 

NOIM 

Integer 

2splanar 

3«nen>pianar 

s 

N 

Integer 

Number  of  seg> 
ments 

3 

T(l) 

Real 

Break  points  of 

e 

e 

piecewise 

e 

5«N 

e 

T(N-l) 

polynomial 
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CURVE  -  (  X(U),  Y(U).  2CU)  >,  FOR  fU)  $  M  $  Till*!) 
N  -  3  SEGNERfS 
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Jli  "  t‘AnArtcZiiiC  SPLlMc 


Index 

Name 

Type 

Otscriotiofl 

4«N 

AX(1) 

Real 

X  coordinate 
polynomial 

7*N 

BX(1) 

t«N 

CX(1) 

f*S 

OX(l) 

10*N 

AY(1) 

Y  coordinate 

11«N 

»Y(1) 

polynomial 

I2*f4 

CY(1) 

13«N 

DY(1) 

U«N 

AZ(1) 

Z  eoordnate 

13*N 

BZ(1) 

polynomial 

1««N 

CZ(1) 

17*N 

OZ(l) 

Subscquant  X,  Y,  Z 
pelyneinuais  eondu^g 
with  th«  twwivw 
CMifieiants  ef  th«  Nth 
potynamial  segment. 

e 

(The  piremeters  thet  (eUew  oempriae  the  eveluetiom  ef  the  pelynemials  of  the  Nth 
segment  and  their  derivatives  at  the  parameter  veiue  imT(N«1)  eerreapending  to  the 
terminate  point.  Subsequently  these  evaluations  are  dvided  by  appropriate  factorials.) 
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112  •  parametric  spline  curve 


TPXO 

Rsal 

X  vaiu* 

TPXl 

X  first  dsrivativ* 

TPX2 

X  second  dtriyative/2! 

tPX3 

X  third  d*rivativ*/3! 

TPYO 

TPYl 

TPY2 

Y  value 

TPY3 

TP20 

TP21 

TPZ2 

TP23 

Z  value 

Addition*!  Pointon  «s  roquirod  (m« 

Softwaro  to  oonvort  botwon  parimotrie  splino  eurvoo  or  surfaeo*  *nd  tho  eerrospondinf 
rational  S^piino  ewvo*  or  surfaeas  is  avaiiablo  from  th*  ICES  offiea  at  dto  National 
Buroau  of  Standards.  Matoriais  provtdad  indudo  a  magnotie  tap*  of  Pascal  sourc*  codo,  a 
Uatinf  of  tho  eodo«  and  aceonipanying  doeumontatian. 
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126  •  RATIONAL  B  SPLINE  CURVE 


Ratioiul  ^SoUfw  Entity 

Th*  rational  S>tpUn«  cirvo  may  rtprosont  analytic  eurvas  of  gonoral  interest. 
This  iniormation  is  important  to  both  the  sending  and  receiving  systems.  The 
dlrecmry  entry  form  number  parameter  is  providod  to  commimicate  this 
information.  It  should  bo  emphasized  that  um  of  this  ewo  form  should  be 
restricted  to  eommimications  between  systems  operating  directly  on  rational  ^ 
spline  cirves  and  net  used  as  a  replacement  for  the  analytic  forms  for 
commuiicatien.  For  a  brief  description  of  a  rational  ^spline  ctrves.  see  Section 
a  of  Appends  0. 

If  the  rational  ^spline  ewe  represents  a  preferred  ewe  type,  the  form  manber 
eorrespends  to  the  most  preferred  type.  The  preference  order  is  from  1  through 
5  foilewed  by  0.  For  eaample,  if  the  ewe  is  a  drele  or  circular  are.  the  form 
number  is  set  to  2.  If  the  ewe  is  an  elilpae  with  lasequal  major  and  minor  axis 
lengths*  the  form  manber  is  set  to  3.  If  the  curve  is  net  one  of  the  preferred 
types,  the  form  number  is  set  to  0. 

If  the  ewe  lies  entirely  within  a  tatidue  plane,  the  planar  flag  (PROP!)  la  set  to 
1,  otherwise  itissetteO.  Ifitlasettol,  dse  plane  normal  (parameters 
ia-*A«aK  through  Ii«A#aK)  contain  a  unit  voetor  normal  to  the  plane  containing 
the  curve.  These  fleida  esdst  but  are  ignored  if  ttm  curve  is  no(>>planar. 
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126 


ra::onal  b  spline  curve 


II  th«  b«^nning  and  ending  points  on  the  curvo  are  identieali  PROP2  is  set  to  1. 
11  they  are  not  equal,  PROP2  is  set  to  0. 


II  the  curve  is  rational  (does  not  have  all  weights  equal),  PROPS  is  set  to  0.  II 
all  weights  are  equal  to'each  other,  the  cirve  is  polynomial  and  PROPS  is  set  to 
1.  The  curve  is  polynomial  since  in  this  ease  all  weighu  cancel  and  the 
denominator  sums  to  one  (see  Appends 


If  the  evrve  is  periodic  with  respect  to  its  parametric  variable,  set  PROPS  to  1, 
otherwise  set  PROPS  to  0. 


S.16.1  Directory  Data 

ENTITY  TYPE  NUMBER:  126 
Meanina 

Form  of  ewe  must  be  determined  from  the  rational  ^spline 
parameters. 

Line 

Creular  are 
Elliptical  are 
Parabolic  are 
Hyperbolic  are 


S>16JI  Parameter  Data 


Indes 

Name 

Im 

Oeaeriotien 

1 

K 

Integer 

Upper  index  of 
sum.  See 
Appendix  0 

2 

M 

Integer 

Degree  of  basis 
(isictions 

S 

PROPl 

Integer 

sO  •  no^vpianar 
sl  •  planar 

S 

PROP2 

Integer 

sO  •  open  cirve 
al  •  closed 
ewe 

3 

PROPS 

Integer 

aO  -  rational 
a  1  •  polynomial 

6 

PROPS 

Integer 

aO  .  noiv 
periodie 
al  -  periodc 

Let  NaK-M*l  and  let  A«N*2M 


Form 

0 

1 

2 

S 

s 

3 
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t26  -  RATIOMAI.  B  SPLIME  SURFAC 


7 

e 

T(-M) 

Real 

Knot  Sequence 

• 

7^A 

e 

e 

T(N*M) 

UA 

e 

W(0) 

a 

Real 

Veighta 

• 

• 

UArK 

e 

a 

W(K) 

9«A«^K 

XO 

Real 

Control  Points 

10*A*K 

YO 

11*A«K 

e 

ZO 

a 

e 

a 

9«A«4K 

a 

a 

XX 

iO«A«AK 

YK 

lUA^AK 

ZX 

12*A«4K 

V(0) 

Real 

Starting  para* 
metw  value 

13«A«4K 

V(l) 

Real 

Ending  par^ 
meter  value 

ia«A«AK 

XNORM 

Real 

Unit  Normal  (if 
cirve  is  planar) 

13*A*AK 

YNORM 

# 

t6«A*«K 

ZNORM 

Adtf  tien«l  Pointtrs  u  rtqutrtd  (sm  Z.2.%.A.2). 

Soltwar*  to  convort  b«tw««n  pvamotric  splin*  eurv«s  or  surfaem  «nd  the  corresponding 
rational  ft«tpUna  curvas  or  surfaces  is  available  from  the  ICES  office  at  the  National 
Bureau  of  Standardai  Materials  provided  include  a  magnetic  tape  of  Pascal  source  cade,  a 
listing  of  the  code,  and  accompanying  documentation. 
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Appendix  D.  CGM  Extracts 
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Grsphiesl  Prlmiiiv*  Omcnrs 


\bitracc  ip«'rinc»tion  of  Eitfrr.pnt 


5.1.10  GENER-KLIZED  DR.\WINC.  PRlNtlTtVE  fCDPl 


P»r«m«t«r«: 


j-n'illi-r  |. 

puint  .i3C  iiPt 
iata  record  :  Ol 

OaMriptiont 

Gtntralixtb  Drawing  Primiiiv*  lODP'  of  the  typ»  <p3cifiH  by  the  identifier  is  5ener.sr»-i  -,n  h* 
buu  of  the  (iven  points  and  the  data  record. 

Non-ne<ltiv»  \aliies  of  tlie  i  l»niili*.r  ir»  re«ervrd  for  reei-tration  ond  future  -t snd.ir  tiiai ion-  ind 
negative  values  are  available  for  pnvaie  use 

The  appearaoee  of  the  COP  is  determined  by  tero  or  more  of  the  attnbute  seu  of  the  staadard* 
ised  paphieal  pnmitive  elements,  dependinp  on  the  particular  COP  The  parameters  of  the  COP 
are  interpreted  and  utilised  in  an  interpreter  dependent  manner 

NOTE  •  COP  provides  convenient  access  to  non-standardlted  iraphieal  primitives  that  a  device 
may  support.  GOP  is  similar  to  ESC.^PE  in  this  sense,  but  COP  previdts  a  mechanism  for  han¬ 
dling  of  coordinau  data  whcreaa  ESCAPE  docs  hot.  GOP  is  thus  preferable  for  genrrstmg 
graphical  output,  and  ESC.\PE  la  dctignsd  for  such  applicatwas  aa  aen-ttaadardiscd  control 
fuactMOS.  ^ 

Wlisn  rsgiatratioa  of  COPs  occurs  there  may  be  regtstersd  GDPs  oliieh  corttspeud  oith  some  of 
the  standardised  msiafils  graphical  pnmitive  tiemsnu.  e.g..  CIRCLE. 

GOP  identifiers  ars  registered  in  the  ISO  tatenaiMoal  Rr(ister  of  Cmphieni  lume.  which  is 
maintained  by  the  Regietraiioa  .\uihomy  When  a  GOP  idfiicifler  has  been  approved  by  the  ISO 
Working  Group  on  Computer  Graphics,  the  COP  idsntifisr  vnut  will  be  aerngned  by  the  Rtgittra- 
tion  .\uthontr 

Refersaeeet 
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Escape  Elements 


Abstract  :*pectfication  of  Elements 


3.d  Escape  Elements 


5.a.l  ESCAPE 


Parameters: 

function  identiAcr  1 1) 
data  record  ( Dl 

Description: 

E5C.\PE  provides  access  to  1ei:c»  capabilities  not  5pec;?i».|  l-i  this  siindard  The  function 
identifier  parameter  specifies  the  particular  escape  function  Non-nefame  i  s.ues  ire  reserved  for 
rcfistration  and  future  standardiiat  ion.  and  negative  values  are  available  for  implementation 
dependant  uaa. 

.NOTE  -  Thia  clement  haa  been  deliberately  underspeetfied.  Software  making  use  of  the  ESC.\PE 
element  is  less  portable. 

ESf'.APE  IS  designed  for  access  to  non-standardised  control  features  of  graphics  devices  as 
opposed  to  non'Stanoardited  geometric  primitives.  The  GENERALIZED  DRAWING  PRIMITD'E 
element  is  designed  for  specification  of  noa>staodardtsad  pnmitivca. 

Function  Kfldtifiers  are  registered  m  the  ISO  (ntamational  Registar  of  Graphical  Items,  which  is 
maintained  by  the  Registratioa  Auchortiy.  When  a  fuaction  identifier  has  been  approved  by  the 
ISO  Working  Group  on  Computer  Graphics,  the  function  identifier  value  «iU  be  aaaigned  by  the 
Regutration  Authority 

Rofufeneani 
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Abitract  Specification  of  Element! 


E«ternal  Elements 


3.9  External  Elements 


5.9.1  message 


Parameters: 

action  required  Haf  i one  of  no  action,  action)  (El 
text  (^) 

Oeacription! 

The  .KESS.-ICE  elsnieni  -pe^’irie^  i  <frini5  of  .-haracter*  iMed  to  .-ommtinif.tte  information  to 
operators  at  Metafile  iiuerpr«taiion  time  tlironfh  a  path  teparaie  from  normal  graphical  output 

If  the  aciton  required  flaf  parameter  is  action  .  the  metafile  mterpretee  may  need  to  pause  to 
wait  for  an  operator  response  Because  the  mesaafc  and  an  associated  pause  may  be  directed  at 
a  particular  device,  only  the  interpreter  may  determine  it  a  pause  is  appropriate.  Character  ret 
selection  for  the  text  parameter  is  indtpendeni  of  any  ehnraetcr  set  selection  specified  by  this 
standard. 

Refereaeent 

1.9 


5.9.3  APPLICATION  DATA 

ParnaiKorsi 

identifier  (II 
data  record  (0) 

Denertptioat 

This  element  supplements  the  information  m  the  metafile  m  an  application-dependent  way  It 
has  no  effect  on  the  picture  generated  by  interpreiinf  the  metafile,  or  on  the  states  of  the 
metafile  generator  or  interpreter 

The  content  of  the  identifier  and  data  record  parameters  is  not  standardized 

NOTE  -  The  ''onienis  of  the  data  record  may  include  such  information  as  history  data  associated 
with  pictures,  description  of  algorithms  used,  etc 

Refnroncans 
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